Kurzfassung
SAP EHS und SAP Product Compliance unterstützen Unternehmen dabei, regulatorische Produktinformationen in operative Abläufe einzubinden. Dazu gehören je nach Systemlandschaft unter anderem Marktfähigkeitsprüfungen, Gefahrgutklassifizierung, Sicherheitsdatenblätter, Kennzeichnung und die Verwendung von Compliance-Status in Folgeprozessen.
Die Begriffe bezeichnen jedoch keine überall identische Systemausprägung. Klassisches SAP EH&S, SAP S/4HANA Product Compliance, angebundene Spezialanwendungen und kundeneigene Erweiterungen können parallel oder in einer Migrationslandschaft vorkommen. Eine belastbare Einordnung beginnt deshalb mit Prozess, Release, aktivierten Komponenten und tatsächlich führenden Datenobjekten.
Fachprozess, Datenobjekt und Systemfunktion trennen
Die drei Ebenen beantworten unterschiedliche Fragen:
| Ebene | Leitfrage | Beispiel |
|---|---|---|
| Fachprozess | Welche Entscheidung muss im Geschäft getroffen werden? | Darf ein Produkt in ein bestimmtes Land verkauft werden? |
| Datenobjekt | Welche Informationen und Beziehungen tragen die Entscheidung? | Produkt, Zusammensetzung, Markt, Anforderungsversion, Bewertung |
| Systemfunktion | Wie wird die Entscheidung gepflegt, geprüft und verwendet? | Fiori-App, Regelprüfung, Workflow, Schnittstelle oder Belegsperre |
Diese Trennung verhindert zwei typische Fehlansätze: einen Fachprozess an eine historisch gewachsene Transaktion anzupassen oder eine technische Migration als rein strukturelle Datenübernahme zu behandeln.
Systemoption statt Selbstzweck
Die technische Lösung beginnt nicht beim Modulnamen, sondern bei Produkten, Rollen, Regeln und Entscheidungen. Erst wenn das fachliche Modell geklärt ist, lässt sich bestimmen, welche Daten in SAP gepflegt, aus Fremdsystemen integriert oder über Schnittstellen bereitgestellt werden müssen.
SAP beschreibt die Compliance View als Sammlung von Compliance-Informationen zu einem Produkt oder Rohstoff. Dazu können unter anderem Produktzuordnungen, Logistikrollen, Zusammensetzungen, Märkte, Produktionsstandorte und Compliance Purposes gehören. Fachlich entscheidend ist nicht die Objektbezeichnung, sondern dass diese Beziehungen vollständig, aktuell und für Bewertungen verwendbar sind.
Einbindung in die Wertschöpfungskette
Compliance-Daten entfalten ihren Nutzen erst in operativen Belegen. Ein vereinfachter Ablauf sieht so aus:
- Ein Produkt wird als compliance-relevant erkannt.
- Grunddaten, Zusammensetzung, Märkte und Anforderungen werden zugeordnet.
- Verantwortliche Rollen erstellen und veröffentlichen Bewertungen.
- Einkauf, Auftrag, Lieferung oder Transport fragen den gültigen Status ab.
- Fehlende oder negative Ergebnisse erzeugen Hinweise, Sperren oder einen Klärvorgang.
- Die Fachrolle ergänzt Daten, bearbeitet die Anfrage und gibt das Ergebnis kontrolliert frei.
Damit wird aus einer Fachbewertung eine operative Entscheidung. Gleichzeitig muss der Weg zurück erhalten bleiben: Eine Sperre sollte erkennen lassen, welches Produkt, welche Anforderung und welcher fehlende Datenstand sie ausgelöst hat.
Integrationslandkarte
Typische Systemgrenzen betreffen:
- Produkt- und Materialstamm sowie organisatorische Zuordnungen,
- Rezepturen, Spezifikationen und Zusammensetzungen,
- Lieferanteninformationen und externe Regulatory-Content-Quellen,
- Regulatory Data und Stofflisten,
- SDS-Authoring, Dokumentverwaltung und Versand,
- Labeling- und Drucksysteme,
- Vertriebs-, Liefer- und Transportbelege,
- Portale, Auswertungen und nachgelagerte Kundenkommunikation.
Für jede Grenze müssen führendes System, fachliche Identität, Änderungsrichtung, Fehlerbehandlung und Freigabestatus geklärt sein. Eine technisch erfolgreiche Übertragung ist noch keine fachlich gültige Integration, wenn beispielsweise Produktversion, Markt oder Status verloren gehen.
Integration und Nachvollziehbarkeit
Freigabestatus, Regelwerksversionen und Produktbezüge müssen in Einkauf, Vertrieb, Lieferung und Dokumentenprozessen konsistent nutzbar sein. SQL, Schnittstellen und ABAP-nahe Erweiterungen können diese Verbindung unterstützen, ohne die fachliche Verantwortung des Product-Compliance-Prozesses zu ersetzen.
Technische Kontrollen sollten mindestens Eindeutigkeit, Pflichtbeziehungen, zulässige Statusübergänge, veraltete Versionen und fehlgeschlagene Übertragungen sichtbar machen. Fachliche Kontrollen prüfen dagegen, ob Regel, Produktkontext und Entscheidung inhaltlich zusammenpassen.
Migration und Weiterentwicklung
Bei einer Migration genügt es nicht, Tabellen oder Dateien vollständig zu übertragen. Vor der Umsetzung sollten Objekte fachlich klassifiziert werden:
- Welche Daten sind führend, historisch oder nur abgeleitet?
- Welche Alt-IDs benötigen eine stabile Zuordnung zu neuen Identitäten?
- Welche offenen Bewertungen und Freigaben dürfen übernommen werden?
- Welche Regeln werden künftig durch Standardfunktionen, Content oder eigene Erweiterungen abgebildet?
- Wie werden Parallelbetrieb, Delta-Übernahme und fachliche Abnahme kontrolliert?
Der SDS Versand Optimierer zeigt als Praxisbeleg, wie SAP-Datenzugriff und ABAP-nahe Logik einen abgegrenzten Dokumentenprozess unterstützen. Er steht damit für eine konkrete Integration – nicht für die pauschale Abbildung des gesamten SAP-EHS- oder Product-Compliance-Umfangs.