SAP-Datasphere-Governance starten

Ausgangslage

SAP-Datasphere-Governance wird häufig als Tool- oder Dokumentationsaufgabe behandelt, obwohl mehrere Teams widersprüchliche Entscheidungen treffen. Spaces, semantische Modelle und Quellsystemberechtigungen verteilen Verantwortung über SAP- und Non-SAP-Grenzen. Dadurch bleiben Zweck, wirksamer Zugriff und fachliche Verantwortung voneinander getrennt. Änderungen werden zwar technisch ausgeliefert, aber Nutzende erfahren zu spät, welche Zusage nicht mehr gilt. Im Audit lässt sich dann ein Screenshot finden, jedoch keine belastbare Kette von Requirement, Entscheidung, Umsetzung und Test.

Begriffe vor dem Lesen

• Fachliche Verantwortung — Die Rolle, die Bedeutung, Zweck und zulässige Nutzung entscheidet; sie bleibt vom Tool-Administrator getrennt.
• Durchsetzungspunkt — Das System, das Zugriff, Veröffentlichung oder technische Änderung tatsächlich erlaubt oder blockiert.
• Nachweis — Verknüpfung aus Entscheidung, Konfiguration, Test, Zeitpunkt und Gültigkeit.
• Negativtest — Gezielter Versuch einer unzulässigen Aktion, der zeigen muss, dass die Kontrolle wirklich blockiert oder eskaliert.

Entscheidung

Der Einstieg klärt für SAP-Datasphere-Governance eine konkrete Entscheidung: wer fachlich entscheiden darf, wo die technische Umsetzung stattfindet und welcher Nachweis zeigt, dass die Regel wirklich wirkt. Ein Business Data Product verbindet Space Verantwortung, Quellvertrag, Semantik, Zugriff, Transport und Nutzende-Abnahme. Der Vertrag benennt enthaltenen und ausgeschlossenen Umfang, Durchsetzungspunkte, Pflichtprüfungen, Evidenzorte und die Frist für Ausnahmen. fachliche Entscheidungsbefugnis bleibt von technischer Administration und unabhängiger Prüfung getrennt. Skalierung beginnt erst, wenn ein produktiver End-to-End-Fall einschließlich Negativtest und Bestätigung durch Nutzende bestanden ist.

Scope und gewünschtes Ergebnis

Der enthaltene Umfang umfasst das ausgewählte Produkt, seine produktiven und nichtproduktiven Umgebungen, menschliche und technische Identitäten, Upstream-Quellen, Downstream-Nutzende, Exporte und relevante Betriebsprozesse. Auch privilegierte Zugriffe und Notfallwege gehören hinein, weil gerade sie reguläre Controls umgehen können.

ausgeschlossener Umfang wird genauso konkret benannt. Benachbarte Domänen, historische Plattformen und geplante Integrationen werden nicht stillschweigend ignoriert, sondern als bekannte Abhängigkeiten oder spätere Wellen registriert. Jede Erweiterung benötigt eine verantwortliche Rolle und einen erneuten Grenze-Check.

Das gewünschte Ergebnis ist ein kleiner, wiederholbarer Betriebsvertrag: Wer entscheidet? Wo wird umgesetzt? Wie wird die tatsächliche Wirkung getestet? Wo liegt die Evidenz? Wann wird neu geprüft?

Operating Model und Entscheidungsrechte

• Business oder Data Owner: bestätigt Bedeutung, erlaubten Zweck, Risikotoleranz und Priorität.
• Data Steward: bereitet Entscheidungen vor, pflegt Kontext und verfolgt Reviews sowie offene Evidenz.
• technischer Betreiber: implementiert die freigegebene Entscheidung sicher und betreibt den Durchsetzungspunkt.
• kontrollverantwortliche Person: definiert das erwartete Kontrollergebnis, die Testmethode und den Ausnahmeprozess.
• Security, Privacy oder Legal: entscheidet oder berät innerhalb des ausdrücklich festgelegten Mandats.
• Nutzer verantwortliche Person: bestätigt Abhängigkeit, Nutzung, Migrationsfähigkeit und Kommunikationsweg.

Pro Entscheidung gibt es genau ein Accountable. Mehrere Teams dürfen beitragen, prüfen oder ausführen; geteilte Accountability erzeugt jedoch Wartezeiten und unklare Eskalation.

Praktischer Workflow

Der Workflow beginnt mit einem realen Produkt und einer bevorstehenden Änderung. Ein abstraktes Zielbild ohne Change, Access Request oder Incident liefert keine belastbare Probe für Rollen und Controls.

Umsetzung in acht überprüfbaren Schritten

Nachweisstandard (alle Schritte): Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle dokumentieren. Fertig ist ein Schritt erst, wenn ein anderer Beteiligter den Nachweis dem Produkt und der wirksamen Version zuordnen kann. Für den Pilot genügt eine repräsentative Stichprobe auf dem produktiven Pfad — kein isolierter Demo-Zugang.

Die nummerierten Schritte sind die Arbeitspakete; Abschluss nur mit Nachweis laut Standard oben.

1. Grenze und Geschäftszweck für SAP-Datasphere-Governance schriftlich festlegen.

Ergebnis: Grenze und Geschäftszweck für SAP-Datasphere-Governance schriftlich festlegen.

2. Accountable verantwortliche Rolle, Steward, Custodian und Control verantwortliche Rolle benennen.

Ergebnis: Accountable verantwortliche Rolle, Steward, Custodian und Control verantwortliche Rolle benennen.

3. Quellen, Nutzende, Identitäten und kritische Übergaben inventarisieren.

Ergebnis: Quellen, Nutzende, Identitäten und kritische Übergaben inventarisieren.

4. Entscheidungsrechte und zulässige Ausnahmen als Matrix freigeben.

Ergebnis: Entscheidungsrechte und zulässige Ausnahmen als Matrix freigeben.

5. Controls am tatsächlichen technischen Durchsetzungspunkt umsetzen.

Ergebnis: Controls am tatsächlichen technischen Durchsetzungspunkt umsetzen.

6. Positiv-, Negativ-, Service- und Bypass-Pfade mit realen Rollen testen.

Ergebnis: Positiv-, Negativ-, Service- und Bypass-Pfade mit realen Rollen testen.

7. Entscheidung, Konfiguration, Testergebnis und Gültigkeit als Nachweispaket verbinden.

Ergebnis: Entscheidung, Konfiguration, Testergebnis und Gültigkeit als Nachweispaket verbinden.

8. Review-Kadenz, Eskalation und Exit-Kriterien für die nächste Welle beschließen.

Ergebnis: Review-Kadenz, Eskalation und Exit-Kriterien für die nächste Welle beschließen.

Identität, Zugriff und Trennung von Aufgaben

Identity ist eine End-to-End-Kette. Corporate Group, Plattformrolle, Service Account, Ressourcengruppe und wirksames Privileg werden gemeinsam betrachtet. Ein sauberer Gruppenname beweist keinen effektiven Zugriff, wenn direkte Grants, lokale Rollen, Verantwortung-Rechte oder Notfallkonten daneben existieren.

Mindestens vier Tests werden protokolliert: erlaubter Standardzugriff, verweigerter Zugriff, Service-Zugriff und privilegierter Bypass. Der Test nennt Identität, Zeitpunkt, Ressource, erwartetes Ergebnis, tatsächliches Ergebnis und verknüpfte Policy-Version.

Metadaten, Lineage und kontrollierte Änderungen

Metadaten werden nicht pauschal an einer Stelle autoritativ. Technische Objekt- und Laufzeitdaten stammen aus der Plattform; fachliche Bedeutung und zulässige Nutzung aus dem freigegebenen Governance-Workflow; Identitäten aus dem Identity Provider; Transformationen aus Code und Deployment-Pipeline.

Eine Änderung ist materiell, wenn sie Bedeutung, Zugriff, Klassifikation, Nutzende-Kompatibilität, Retention, Kontrollwirkung oder Betriebsrisiko verändert. Materielle Änderungen erhalten Impact Assessment, Entscheidung, getestete Umsetzung, Kommunikationsplan und gegebenenfalls Migrationsfrist.

Evidenz, Tests und Ausnahmen

Der minimale Nachweispaket enthält Umfang, Authority, Durchsetzungspunkte, Tests und Prüfdatum. Jeder Nachweis trägt Produkt-ID, Control- oder Policy-Version, Erzeugungszeitpunkt, verantwortliche Rolle, Gültigkeitszeitraum und Link zur zugrunde liegenden Entscheidung.

Eine Exception ist eine zeitlich begrenzte Entscheidung, kein Kommentar im Ticket. Sie enthält Umfang, Risiko, Begründung, kompensierende Maßnahmen, accountable Genehmiger, Ablaufdatum, Remediation verantwortliche Rolle und ein Signal für die automatische Wiedervorlage.

Betrieb, Incidents und Review-Kadenz

Governance wird in Change-, Access-, Incident- und Produktprozesse eingebaut. Monatlich werden offene Ausnahmen, überfällige Reviews, fehlgeschlagene Tests und verwaiste Assets betrachtet. Quartalsweise wird geprüft, ob Umfang, Rollen und Control Design noch angemessen sind.

Häufige Anti-Patterns

Das Tool wird zum verantwortliche Rolle erklärt

Eine Plattform zeichnet Konfiguration auf, kann aber kein Geschäftsrisiko akzeptieren oder konkurrierende Zwecke entscheiden.

Policy-Name ersetzt Wirksamkeit

Gleiche Bezeichnungen beweisen keine gleichwertige Wirkung über Identitäten, Ressourcen und Zugriffspfade.

Evidenz wird vor dem Audit gebaut

Nachgebaute Evidenz ist teuer und repräsentiert möglicherweise nicht den tatsächlich betriebenen Zustand.

Ausnahmen haben kein Ablaufdatum

Dauerhaft temporärer Zugriff wird zu einem undokumentierten alternativen Operating Model.

Praktische Umsetzung

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Schritt 1: Grenze und Baseline

Produkt, verantwortliche Rolle, Nutzende, Identitäten, Datenflüsse, Controls, Ausnahmen und aktuelle Nachweise aufnehmen. Drei konkrete Risiken priorisieren.

Schritt 2: Entscheidungen und Design

Authority Matrix, Policy- beziehungsweise Contract-Entscheidungen, Testfälle und Nachweisorte freigeben.

Schritt 3: Implementieren und testen

Controls über den echten Pfad ausrollen. Positive, negative, Service- und Bypass-Tests durchführen.

Schritt 4: Änderung und Incident simulieren

Eine materielle Änderung sowie einen Betriebs- oder Zugriffsvorfall durch Rollen, Kommunikation und Evidenzkette führen.

Schritt 5: Prüfung und Skalierungsentscheidung

Wirksamkeit, Aufwand und offene Ausnahmen bewerten. Nur nach bestandener Stichprobe skalieren.

Messung und Exit-Kriterien

• Anteil kritischer Assets mit bestätigtem verantwortliche Person, Nutzerinnen und Nutzerinnen und Nutzer und Prüfdatum
• Anteil getesteter Kontrollregeln mit aktueller, reproduzierbarer Evidenz
• Zeit von Access Request oder Change bis zur accountable Entscheidung
• Anzahl und Alter offener Ausnahmen sowie Anteil ohne Remediation-Fortschritt
• Aufwand zur Rekonstruktion einer Stichprobe von Requirement bis wirksamer Plattformversion

Checkliste

• enthaltener und ausgeschlossener Umfang und gewünschtes Ergebnis sind schriftlich bestätigt.
• Pro kritischer Entscheidung existiert genau ein Accountable.
• fachliche Entscheidungsbefugnis, technische Administration und unabhängige Prüfung sind getrennt.
• Positive, negative, Service- und Bypass-Pfade wurden mit realistischen Identitäten getestet.
• Evidenz nennt Version, Zeitpunkt, verantwortliche Person, Umfang und Gültigkeit.
• Ausnahmen besitzen Risiko, kompensierende Kontrolle, Ablauf und verantwortliche Person für die Behebung.
• Die Skalierungsentscheidung basiert auf einer bestandenen End-to-End-Stichprobe.

Artefakt

Das Ergebnis ist eine Governance-Nachweis für SAP-Datasphere-Governance: Abgrenzung, Entscheidungsrechte, Kontrollen und Nachweise. Sie dokumentiert Umfang, Produkt-ID, Entscheidungsbefugnis je Zweckbereich, technische Durchsetzungspunkte, Rollen, Tests, Nachweisorte, offene Konflikte, Ausnahmen und Prüfdatum.

Tools und Verweise

Nutze einen Decision Log, eine Authority Matrix, einen Control-Testbogen und ein versioniertes Nachweise Register.