Datenmodell Rückverfolgbarkeit: 8 Felder, die wirklich zählen

Wer Rückverfolgbarkeit in der Fertigung einführen will, stolpert meistens über dieselbe Frage: Was muss ich überhaupt erfassen? Die Antworten, die man bekommt, fallen in zwei Extreme. Entweder: 'Alles – Datum, Uhrzeit, Maschine, Werkzeug, Temperatur, Luftfeuchtigkeit, Benutzer, Schicht …' Oder: 'Einfach eine Nummer pro Teil.' Beide Antworten sind falsch.

Das erste Extrem erzeugt Datengräber: Terabytes an Produktionsdaten, die im Audit niemand finden kann und im Recall-Fall niemand schnell auswerten kann. Das zweite Extrem erzeugt Lückennachweise: Eine Nummer existiert, aber sie lässt sich nicht mit dem Fertigungsablauf, dem Materialeingang oder dem Prüfergebnis verknüpfen.

Dieser Artikel beschreibt das minimale Datenmodell für Rückverfolgbarkeit in der Serienfertigung: 8 Felder, die in jeder Datenstruktur vorhanden sein müssen – nicht weil Normen es fordern, sondern weil ohne sie Rückverfolgbarkeit im Ernstfall nicht funktioniert. Mit konkreten Datentypen, Beispielwerten und dem Norm-Mapping für IATF 16949, ISO 9001 und EU MDR.

Was ein Traceability-Datenmodell leisten muss

Bevor die 8 Felder beschrieben werden, muss klar sein, was das Datenmodell leisten soll. Rückverfolgbarkeit ist kein Selbstzweck. Sie ist die strukturierte Antwort auf vier Fragen, die in zwei Situationen gestellt werden: beim Audit und beim Rückruf.

Ein Datenmodell, das diese vier Fragen für jedes ausgelieferte Produkt beantworten kann – und zwar schnell, lückenlos und unveränderlich – ist ein audit-taugliches Traceability-Datenmodell. Eines, das auch nur eine dieser Fragen nicht vollständig beantworten kann, ist es nicht.

Die 8 Pflichtfelder sind so gewählt, dass jede dieser vier Fragen durch mindestens zwei Felder belegt wird. Das schafft Redundanz: Selbst wenn ein Nachweis fehlt oder angezweifelt wird, existiert ein zweiter, der dieselbe Frage beantwortet.

Das Schema: 8 Pflichtfelder im Überblick

Die folgende Referenztabelle zeigt das vollständige minimale Datenmodell. Alle 8 Felder sind als Pflichtfelder definiert – kein Datensatz ohne alle 8. Weitere Felder sind branchen- und prozessspezifisch sinnvoll, aber optional.

Die 8 Felder im Detail

Jedes Pflichtfeld hat eine spezifische Funktion in der Nachweiskette. Die folgenden Karten erklären für jedes Feld: Was es ist, welchen Datentyp es haben muss, was ohne dieses Feld im Audit oder Rückruffall fehlt – und welche Frage der Auditor stellt, die dieses Feld beantworten muss.

Feld 01 – Einheitenidentität

Feld 02 – Fertigungsauftrag

Feld 03 – Zeitstempel Fertigung

Feld 04 – Materialcharge(n)

Feld 05 – Prüfergebnis

Feld 06 – Prozessparameter-Referenz

Feld 07 – Auslieferungsnachweis

Feld 08 – Änderungskennung (ECR-Referenz)

Häufige Formatfehler und wie man sie vermeidet

Die 8 Felder sind bekannt – aber in der Praxis werden sie häufig in Formaten erfasst, die im Audit oder Rückruffall wertlos sind. Die folgende Tabelle zeigt die häufigsten Formatfehler je Pflichtfeld.

Norm-Mapping: Welche Norm fordert welche Felder

Die 8 Pflichtfelder sind nicht willkürlich – sie sind aus den Anforderungen der relevantesten Normen und Regulierungen in der DACH-Fertigung destilliert. Das folgende Mapping zeigt, welche Felder von welchen Normen explizit oder implizit gefordert werden.

Das minimale Datenmodell ist nicht das, was Normen fordern. Es ist das, was im Schadensfall tatsächlich hilft – und das deckt sich bemerkenswerterweise sehr gut mit dem, was Normen fordern.

— Amadeus Lederle CTE, CSP Intelligence GmbH

Implementierungspfad: Die 8 Felder in drei Phasen einführen

Die 8 Pflichtfelder lassen sich nicht in einer Woche einführen – aber auch nicht erst in einem Jahr. Der folgende Implementierungspfad zeigt, welche Felder wann eingeführt werden sollten, in welcher Reihenfolge der Aufwand und Nutzen optimal sind.

Der gemeinsame Schlüssel: Warum Verknüpfung wichtiger ist als Vollständigkeit

Es gibt Unternehmen, die alle 8 Felder in ihren Systemen haben – und trotzdem nicht rückverfolgbar sind. Der Grund: Die Felder existieren in verschiedenen Systemen ohne gemeinsamen Schlüssel. Das Prüfergebnis ist in der Qualitätssoftware. Die Materialcharge ist im ERP. Der Prozessparameter ist im MES. Und die Seriennummer, die alles verbinden würde, ist in keinem dieser Systeme konsequent gepflegt.

Der gemeinsame Schlüssel – die Einheitenidentität aus Feld 1 – muss in allen Systemen als Primärschlüssel geführt werden. Nicht als optionales Referenzfeld. Nicht als Freitextfeld, das manchmal ausgefüllt wird. Sondern als Pflichtfeld, ohne das kein Datensatz in keinem System abgeschlossen werden kann.

Das minimale Datenmodell nativ implementiert

PRAXISTIPP

Alle 8 Pflichtfelder nativ und verknüpft

CSP IPM implementiert alle 8 Pflichtfelder des minimalen Traceability-Datenmodells nativ und verknüpft – mit der Einheitenidentität (Seriennummer oder Charge) als durchgehendem Schlüssel von Materialeingang bis Auslieferung. Kein Datenchaos, keine Systembrüche, keine fehlenden Verknüpfungen.

• Feld 1–8 vollständig implementiert: kein manuelles Mapping zwischen Systemen nötig
• Barcode/QR/RFID-Scan bei jedem Schritt: Einheitenidentität automatisch als Schlüssel übernommen
• Unveränderliche Zeitstempel: maschinengesetzt, revisionssicher, GoBD- und MDR-konform
• Prozessparameter-Protokoll automatisch je Seriennummer: Schrauber, Schweißgeräte, Prüfstationen direkt angebunden
• Chargenverknüpfung: Lieferantencharge → Wareneingang → Fertigungsauftrag → Seriennummer – ein Klick, vollständige Kette
• Sofortabruf aller 8 Felder je Einheit: Im Audit vollständiger Datensatz in < 60 Sekunden exportierbar

→ Demo vereinbaren

Häufig gestellte Fragen

Reichen 8 Felder wirklich für IATF 16949?

Für die Rückverfolgbarkeit als solche ja – IATF 16949, Abschnitt 8.5.2, fordert die Fähigkeit, Produkte entlang der Wertschöpfungskette zurückverfolgen zu können. Die 8 Pflichtfelder erfüllen diese Anforderung. IATF 16949 fordert darüber hinaus jedoch weitere Qualitätsnachweise (z.B. Erstmusterprüfung, Produktionslenkungsplan, Messsystemanalyse), die nicht Teil des Traceability-Datenmodells sind. Das minimale Datenmodell ist der Traceability-Kern – es ersetzt nicht das gesamte Qualitätsmanagementsystem.

Wie unterscheidet sich das Datenmodell für Serialisierung vs. Chargenverfolgung?

Das Datenmodell ist strukturell identisch – nur Feld 1 unterscheidet sich im Granulierungsgrad. Bei Serialisierung ist Feld 1 eine Seriennummer, die genau eine Einheit identifiziert. Bei Chargenverfolgung ist Feld 1 eine Chargennummer, die eine Gruppe von Einheiten identifiziert. Alle anderen 7 Felder funktionieren bei beiden Methoden gleich. Die Entscheidung zwischen Serialisierung und Chargenverfolgung beeinflusst Feld 1 – das zugrundeliegende Datenmodell bleibt dasselbe.

Muss Feld 4 (Materialcharge) alle Rohmaterialien oder nur kritische Materialien erfassen?

Das hängt von der Risikoklasse des Produkts und den geltenden Normen ab. Für sicherheitsrelevante Produkte (Automotive, Medizintechnik, Luftfahrt) sollten alle sicherheitsrelevanten Materialien erfasst sein – inklusive Zukaufkomponenten. Für niedrigrisikoklassen kann eine Beschränkung auf primäre Werkstoffe und sicherheitskritische Komponenten ausreichend sein. Als pragmatische Regel: Alles erfassen, was bei einem Materialfehler zu einem Rückruf führen könnte.

Kann Feld 6 (Prozessparameter-Referenz) eine einfache Excel-Datei sein?

Technisch ja – aber praktisch nicht audit-tauglich. Excel-Dateien sind manuell editierbar, nicht revisionssicher und nicht unveränderlich. Im Audit oder Haftungsfall kann ein Gegner argumentieren, dass die Datei nachträglich verändert wurde. Feld 6 muss auf ein systemgeneriertes, unveränderliches Protokoll verweisen – idealerweise mit Zeitstempel und digitaler Signatur. CSV-Exporte aus einem MES/IPM mit entsprechendem Archivierungs-Backend sind akzeptabel, wenn die Unveränderlichkeit durch Archivierung sichergestellt ist.

Wie weit zurück müssen die 8 Felder für ältere Produkte nachgepflegt werden?

Nachpflegen ist in den meisten Fällen nicht möglich – historische Produktionsdaten, die nicht erfasst wurden, können nicht rekonstruiert werden. Der pragmatische Ansatz: Stichtag festlegen, ab dem alle 8 Felder für neue Produkte vollständig erfasst werden. Für Produkte vor dem Stichtag: soweit wie möglich aus vorhandenen Quellen ergänzen (Prüfprotokolle, Lieferscheine, ERP-Daten). Den Stichtag in der Dokumentation vermerken, damit im Audit klar ist, ab wann das vollständige Modell gilt.

Was ist der Unterschied zwischen Feld 6 (Prozessparameter-Referenz) und dem eigentlichen Prozessprotokoll?

Feld 6 ist ein Zeiger, nicht das Protokoll selbst. Der Datensatz eines einzelnen Produkts enthält eine Referenz-ID, über die das vollständige Prozessprotokoll im System gefunden wird. Das Prozessprotokoll selbst kann viele Megabyte umfassen (bei Schraubdaten, Schweißkurven, Inline-Messdaten), ist aber nicht Teil des kompakten 8-Felder-Datensatzes. Diese Trennung ist bewusst: Der Stammdatensatz bleibt übersichtlich und schnell ladbar, während die Rohdaten bei Bedarf über die Referenz-ID abgerufen werden können.

Warum ist Feld 8 (Änderungskennung) ein Pflichtfeld – und kein optionales Feld?

Weil Konstruktionsänderungen (Engineering Change Records) in der Praxis regelmäßig auftreten – und weil Qualitätsprobleme oft genau an den Übergangszeitpunkten entstehen. Ein Produkt, das am Tag vor dem Wechsel auf eine neue Konstruktionsversion hergestellt wurde, hat andere Eigenschaften als eines, das am Tag danach hergestellt wurde. Ohne Änderungskennung kann im Fehlerfall nicht abgegrenzt werden, ob das Problem in der alten oder neuen Version liegt – und wie viele Produkte betroffen sind.

Wie viele dieser 8 Felder sind typischerweise in bestehenden ERP-Systemen bereits vorhanden?

In einer typischen SAP- oder Dynamics-Installation sind Felder 2 (Fertigungsauftrag), 5 (Prüfergebnis, rudimentär) und 7 (Auslieferungsnachweis) oft vorhanden. Felder 1 (Einheitenidentität als durchgehender Schlüssel), 3 (maschinengesetzter Zeitstempel), 4 (vollständige Chargenverknüpfung), 6 (Prozessparameter-Referenz) und 8 (Änderungskennung) sind in reinen ERP-Systemen selten vollständig implementiert. Das ist kein ERP-Problem – es ist ein Schnittstellenproblem: ERP kennt den Auftrag, aber nicht die Linie. Genau hier ist ein integriertes MES/IPM die strukturelle Lösung.