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.
Von der SDS-Angabe zum prüfbaren Einstufungsbefund
Bei der Gemischbewertung verbindet Regulatory Data zwei unterschiedliche Aufgaben: Angaben aus einem Dokument nachvollziehbar erfassen und sie für einen bestimmten Endpunkt qualifizieren. Ein korrekt übertragener Text ist dabei noch kein bestätigter Rechenparameter.
Das synthetische SDS-Praxisbeispiel zeigt eine Stoffzeile mit einem Konzentrationsbereich, aber ohne gesicherte Bezugsbasis. Für den nächsten Schritt müssen die zusammengehörigen Angaben getrennt prüfbar bleiben:
| Datenebene | Was zusammengehört | Was daraus noch nicht folgt |
|---|---|---|
| Quellbeleg | Original, Dokumentversion, Abschnitt und Fundstelle | Der erkannte Text ist fachlich bestätigt |
| Zuordnung | Stoffidentität, Bestandteil und bewertetes Gemisch | Ein Namens- oder Kennnummerntreffer klärt jeden Stoffumfang |
| Mengenangabe | Wert oder Bereich, offene/geschlossene Grenzen, Einheit und Massen-/Volumenbezug | Ein Prozentzeichen genügt als Rechengrundlage |
| Endpunktparameter | Zugehörige Einstufung, gegebenenfalls SCL, ATE oder M-Faktor, Quelle und Geltungsbereich | Eine Lieferantenangabe gilt automatisch für jedes Verfahren |
| Entscheidung | Gewählte Methode, verwendete Eingaben, Befund und Prüfstatus | Eine Rechenvorschau ist eine Freigabe des gesamten Produkts |
Fehlt die Bezugsbasis, bleibt genau diese Voraussetzung offen. Eine Quelle ohne ATE-Wert bedeutet nicht den Wert null; eine fehlende Einstufungsangabe bedeutet nicht „nicht gefährlich“. Weichen Quellen voneinander ab, wird der Konflikt sichtbar gehalten, bis eine begründete Auswahl für den passenden Geltungsbereich vorliegt. Lieferantenangaben, harmonisierte Einstufungen und fachlich bestätigte Parameter sind deshalb unterscheidbare Datensätze.
Sind die Voraussetzungen für das unterstützte Verfahren geklärt, kann ein Konzentrationsbereich in die Bereichsbewertung eingehen. Das synthetische CLP-Beispiel zeigt getrennt davon, weshalb auch qualifizierte Eingaben eine offene Entscheidung ergeben können. Es ist ein eigenständiges Modell mit fiktivem Grenzwert und keine Weiterrechnung der unbestätigten Angaben aus dem SDS-Beispiel.
Die Projektbeschreibung der Compliance Tools zeigt die technische Verbindung von Quellenprüfung, Stoffdatenpflege und begrenzten Bewertungsbefunden. Die Anwendung bleibt intern. Diese Datenstruktur unterstützt Nachvollziehbarkeit; sie ersetzt weder fehlende Parameterbelege noch die fachliche Abnahme eines konkreten Produkts.
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.
Kompetenz und Umsetzung
Das Arbeitsfeld Regulatory Data Management verbindet fachliche Datenpflege und Qualitätssicherung. Die technische Umsetzung lässt sich zusätzlich über TypeScript, Clean Code und Testing einordnen. Als konkreter Praxisbeleg dient die öffentliche Compliance-Tools-Projektbeschreibung; die Anwendung und private Nachweise bleiben intern.