Kurzfassung
Regulatory Data umfasst die strukturierten Informationen, mit denen regulatorische Anforderungen bewertet, dokumentiert und operativ angewendet werden. Dazu gehören nicht nur Stofflisten, sondern auch Gültigkeiten, Rechtsräume, Quellen, Versionen, Schwellenwerte, Entscheidungen und Freigaben.
Der entscheidende Unterschied zu einer Dokumentablage liegt in den Beziehungen: Regulatory Data macht sichtbar, welche Anforderung für welches Objekt, in welchem Kontext und zu welchem Zeitpunkt gilt. Damit bildet es das Datenrückgrat für Product Compliance.
Ebenen eines regulatorischen Datenmodells
Ein tragfähiges Modell trennt fachliche Ebenen, die in Tabellenkalkulationen oder Dokumenten häufig vermischt werden:
| Ebene | Beispiele | Warum sie eigenständig bleibt |
|---|---|---|
| Identität | Stoff, Produkt, Material, Rezeptur, Lieferant | Namen und System-IDs können sich ändern |
| Anforderung | Regelwerk, Stoffliste, Kundenstandard | eine Anforderung gilt nicht automatisch überall |
| Version | Veröffentlichungsstand, Inkrafttreten, Übergangsfrist | Bewertungen müssen zeitlich reproduzierbar sein |
| Kontext | Rechtsraum, Markt, Verwendung, Lieferweg | derselbe Gegenstand kann unterschiedlich bewertet werden |
| Fakt | Zusammensetzung, Konzentration, Klassifizierung, Dokument | Fakten stammen aus unterschiedlichen Quellen |
| Bewertung | betroffen, konform, eingeschränkt, ungeklärt | Ergebnis einer Regelanwendung oder Fachentscheidung |
| Governance | Status, Verantwortlicher, Freigabe, Quelle | macht Herkunft und Verbindlichkeit prüfbar |
Diese Trennung verhindert, dass ein angezeigter Status seine fachliche Bedeutung verliert. „Konform“ ist ohne Produktbezug, Anforderungsversion, Markt und Bewertungsdatum keine dauerhaft verwertbare Aussage.
Daten brauchen Kontext
Ein Stoffname oder Status allein ist nicht belastbar. Erst die Beziehung zu Produkt, Rezeptur, Markt, Regelwerk und Bewertungszeitpunkt macht aus einem Wert eine nachvollziehbare regulatorische Information. Änderungen müssen deshalb versioniert und ihre Auswirkungen auf betroffene Produkte ermittelt werden.
Ein vereinfachter, systemneutraler Bewertungsschlüssel kann aus folgenden Elementen bestehen:
Produktversion + Anforderungsversion + Markt + Verwendung + Bewertungszeitpunkt
Das Ergebnis verweist zusätzlich auf Eingabedaten, Regel, Bearbeitungsstatus, Begründung und Freigabe. Diese Struktur unterstützt sowohl automatisierte Prüfungen als auch manuelle Entscheidungen, ohne beide gleichzusetzen.
Lebenszyklus statt Stammdatenpflege
Regulatory Data durchläuft einen kontrollierten Lebenszyklus:
- Quellen beobachten und Änderungen erfassen,
- neue Inhalte fachlich einordnen und versionieren,
- betroffene Datenobjekte und Produkte ermitteln,
- Daten beschaffen, normalisieren und validieren,
- Regeln anwenden oder Bewertungen anfordern,
- Ergebnisse prüfen und freigeben,
- Status, Dokumente und operative Prozesse aktualisieren,
- Herkunft und Entscheidung langfristig nachvollziehbar halten.
Die Kommunikation in der Lieferkette ist dabei keine Einbahnstraße. Lieferantendaten fließen in Bewertungen ein; freigegebene Ergebnisse werden als Sicherheitsdatenblatt, Erklärung, Portalantwort oder strukturierter Datensatz an nachgelagerte Empfänger weitergegeben.
Datenqualität messbar machen
Vollständigkeit allein genügt nicht. Relevante Qualitätsdimensionen sind:
- Eindeutigkeit: stabile fachliche Identitäten statt mehrfacher Freitexte,
- Gültigkeit: fachlich zulässige Werte, Einheiten und Beziehungen,
- Konsistenz: widerspruchsfreie Aussagen über Systeme und Dokumente hinweg,
- Aktualität: Bezug zum gültigen Produkt- und Regelstand,
- Herkunft: dokumentierte Quelle und Transformationsschritte,
- Freigabe: klarer Bearbeitungs- und Verantwortungsstatus,
- Auswirkbarkeit: Beziehungen, über die betroffene Produkte gefunden werden.
Qualitätsregeln sollten technische Fehler und fachliche Klärfälle unterscheiden. Ein ungültiges Datumsformat kann automatisiert abgewiesen werden; eine widersprüchliche Lieferantenaussage benötigt meist eine verantwortliche Entscheidung.
Technische Umsetzung
Ein systemneutrales Domänenmodell trennt fachliche Identitäten von den IDs einzelner Quellsysteme. Validierungsregeln, Historie und Freigabestatus machen die Daten anschließend für Schnittstellen, Datenbanken, Berichte oder SAP EHS verwendbar.
Für die Integration sind drei Grenzen besonders wichtig:
- Das führende System pro Datenobjekt muss festgelegt sein.
- Schnittstellen übertragen neben Werten auch Identität, Version und Status.
- Abgeleitete Daten bleiben mit ihren Eingaben und Regeln verknüpft.
Damit wird Regulatory Data nicht zu einer neuen parallelen Datenablage, sondern zu einem kontrollierten Modell für die Nutzung vorhandener Fachinformationen. Der Change-Management-Prozess zeigt, wie Änderungen von der Quelle bis zur operativen Wirkung geführt werden.