Verantwortung und Stewardship auf Argonos

zt“ das Produkt. Das ist administrativ bequem und governance-technisch falsch. Admin-Recht ist Durchsetzungsmacht; Verantwortung ist Entscheidungsrecht über Zweck, Risiko und Priorität. Beides kann in derselben Person liegen — es darf aber nicht stillschweigend gleichgesetzt werden.

Lösung: Trenne strikt zwischen Entscheidungsrecht und Umsetzungsmacht.

In einem Satz: Trenne strikt zwischen Entscheidungsrecht und Umsetzungsmacht.

Problem

Sobald eine Decision-Plattform Workspaces, Rechte und Freigaben anbietet, wird Verantwortung gern mit Admin-Recht verwechselt. Wer den Space anlegen oder Rollen vergeben darf, „besitzt“ das Produkt. Das ist administrativ bequem und governance-technisch falsch. Admin-Recht ist Durchsetzungsmacht; Verantwortung ist Entscheidungsrecht über Zweck, Risiko und Priorität. Beides kann in derselben Person liegen — es darf aber nicht stillschweigend gleichgesetzt werden.

Auf souveränen Deployments (On-Prem, souveräne Cloud, air-gapped) kommt ein zweites Muster hinzu: Delivery- und Support-Teams — intern oder beim Hersteller — haben faktisch mehr Änderungsmacht als der benannte Data Owner. Verantwortung existiert im RACI; Change passiert im Ticket des Lieferanten. Die Organisation glaubt, sie habe Accountability, weil ein Name in einer Matrix steht. Der Betrieb glaubt, er habe Freigabe, weil jemand mit Admin-Recht „ja“ gesagt hat.

Der dritte Fehler ist die Annahme, Stewardship sei Dokumentation. Stewards pflegen Glossare und Klassifikationen, dürfen aber Reviews nicht blockieren und dürfen Risiko nicht sichtbar machen. Dann entsteht ein Parallelbetrieb: Die Plattform läuft, der Owner ist erreichbar, und trotzdem entscheidet niemand belastbar über neue Zwecke, verlängerte Aufbewahrung oder akzeptiertes Restrisiko. Einstieg und Abgrenzung: Argonos als Betriebsgrenze, Konzept: Data Verantwortung & Stewardship, Rahmen: Eight Pillars.

Entscheidung

Trenne strikt zwischen Entscheidungsrecht und Umsetzungsmacht. Data Owner und Data Steward sind Organisationsrollen; Platform Custodian und Vendor-/Plattform-Admin sind Betriebsrollen. Genau ein Accountable pro Decision Object. Mehrere Contributors sind erlaubt; geteilte Accountability ist es nicht.

Der Pilot umfasst ein Decision-Produkt in einem Tenant/Deployment mit Owner, Steward, Custodian und Support-Pfad. Erfolg ist messbar: Eine unbeteiligte Person kann in unter 30 Minuten sagen, wer Zweck und Risiko akzeptiert, wer Änderungen freigibt und wer nur umsetzt — inklusive Support-Pfad.

Scope und Abgrenzung

Scope-in sind ein Decision-Produkt mit Product Identifier, zugehörige Workspaces/Projekte, Human- und Service-Identities mit Änderungsrechten, Support-Konten, Change-Pfad und Recert-Zyklus. Der Scope umfasst auch Stellvertretung und Eskalation, sonst ist Verantwortung nur eine Tagesperson.

Scope-out sind Catalog-, Warehouse- und BI-Verantwortung außerhalb der Plattform, sofern sie nicht als Übergabe benannt sind. Multi-Stack-Fälle brauchen eine Authority pro Zweckbereich — siehe Governance über mehrere Plattformen. Souveränität ändert diese Regeln nicht: Ein EU-naher Hersteller ersetzt keinen Steward. Residenz bleibt ein Vertragsthema (Host vs Cloud).

Nicht Ziel ist ein Rollenkatalog mit Dutzenden Titeln. Ziel ist eine kurze, belastbare Kette: Entscheidung → Freigabe → Umsetzung → Nachweis.

Rollen und Entscheidungsrechte

• Data Owner: accountable für Zweck, erlaubte Nutzung, Klassifikationsfreigabe und Risikoakzeptanz.
• Data Steward: bereitet Reviews vor, hält Kontext und Widersprüche sichtbar, eskaliert Konflikte.
• Platform technischer Betreiber: setzt genehmigte Rechte, Spaces und Kontrollregeln um; führt Change-Log.
• Dienstleister-/Support-Admin: arbeitet nur in freigegebenen Zeitfenstern und Zwecken; nie als stiller verantwortliche Person.
• kontrollverantwortliche Person: definiert Recert, Ausnahmeweg und Testdichte für Verantwortung-Kontrollregeln.
• Nachweis verantwortliche Person: stellt sicher, dass Freigaben, Recerts und Ausnahmen auffindbar und versioniert sind.

Der Platform Custodian darf technische Defaults vorschlagen. Er darf nicht allein entscheiden, dass ein neuer Consumer-Zweck „offensichtlich harmlos“ ist. Diese Grenze schützt beide Seiten: den Custodian vor faktischer Haftung ohne Mandat und den Owner vor Schein-Accountability.

Product Record außerhalb der UI

Verantwortung, die nur in der Plattform-UI existiert, stirbt mit dem nächsten Workspace-Rename. Führe einen Product Record außerhalb der UI — als betriebene Tabelle, Catalog-Eintrag oder versioniertes Dokument — mit mindestens:

• stabilem Product Identifier
• Data Owner und Steward (Person + Stellvertretung)
• Kritikalität und erlaubter Zweck
• Deployment-Bezug (On-Prem / souverän / air-gapped)
• Mapping zu Spaces/Projekten in Argonos
• Nutzer-Liste und bekannte Übergaben
• nächstem Recert-Datum

Der Product Record ist die Authority für „was das Produkt ist“. Die Plattform spiegelt Zuordnungen; sie ist nicht die einzige Wahrheit. Änderungen am Record erzeugen eine neue Version und lösen gezielte Nachtests an Access und Übergaben aus.

Operating Model auf der Plattform

Workspace-/Project-Mapping

Jeder Space, der produktrelevante Daten trägt, ist einem Product Record zugeordnet. Orphan-Spaces sind Findings. Gemeinsame Spaces brauchen einen Primary Owner und dokumentierte Mitnutzer — sonst entsteht geteilte Nicht-Verantwortung.

Change-Pfad

Wer beantragt, wer freigibt, wer umsetzt — getrennt für interne Custodians und Hersteller-Support. Ein Change ohne Owner-Freigabe ist entweder unmöglich oder als Ausnahme mit Ablaufdatum geführt. „Hotfix vom Admin“ ohne Record ist ein Anti-Muster, kein Agile-Bonus.

Recertification

Owner, privilegierte Admins und Support-Konten werden periodisch bestätigt. Recert ohne Konsequenz (Entzug, Ausnahme, Eskalation) ändert nichts am Zugriff. Parallel: Access Recertification.

Consumer Owner

Ohne Consumer Owner meldet niemand Migrationsbedarf, Zweckdrift oder Schattenkopien. Consumer Verantwortung ist Teil der Betriebsgrenze, nicht ein nachgelagertes Nice-to-have.

Support, Vendor und Delivery als Contributors

Souveräne Deployments verschieben oft nur den Ort der Admins. Governance-relevant bleibt:

• namentlicher interner Sponsor für jeden Support-Zugang
• Zweck, Zeitfenster und Audit-Erwartung im Vertrag bzw. Betriebsvereinbarung
• Abbildung als Contributor, nie als Accountable für Business Purpose
• Expiry und Recert wie bei Break-Glass

Delivery-Projekte dürfen Spaces aufbauen. Sie dürfen Verantwortung nicht „mitliefern“ und nach Go-Live unbenannt lassen. Handover ohne Product Record und ohne bestätigten Owner ist kein Go-Live.

Authority-Matrix für Verantwortung-Zweckbereichs

Nutze den Authority Matrix Builder mindestens für:

• Business Purpose / erlaubte Nutzung
• Verantwortung-Zuweisung und Stellvertretung
• Access-Richtlinie-Freigabe
• Klassifikation / Sensitivität (soweit im Produkt relevant)
• Ausnahme und Risikoakzeptanz

Eine Authority pro Zweckbereich. Wenn Argonos und ein Unternehmens-Catalog denselben Zweckbereich beanspruchen, braucht es einen Sync-Vertrag — sonst konkurrierende Wahrheiten. Vergleichsrahmen: Palantir und Argonos.

Häufige Anti-Muster

Admin-Gruppe = Owner-Gruppe

Durchsetzungsmacht wird mit Entscheidungsrecht verwechselt. Reviews und Risikoakzeptanz landen bei denen, die Tasten drücken können.

Steward nur als Dokumentationsrolle

Ohne Review-Recht und Eskalationsweg ist Stewardship Dekoration. Widersprüche bleiben unsichtbar, bis ein Audit sie findet.

Support-Account ohne Owner und ohne Expiry

Dauerhafter Hersteller- oder Betriebszugang ist ein zweites Betriebsmodell. Souveränität ändert daran nichts.

Produkt ohne Consumer Owner

Niemand meldet Zweckdrift, Migrationsbedarf oder Schattenkopien. Die Plattform „läuft“, Accountability driftet.

Verantwortung nur in der UI

Workspace-Rename, Projektarchivierung oder Lieferantenwechsel löschen die einzige Wahrheit über den Owner.

Geteilte Accountability „zur Sicherheit“

Zwei Accountables bedeuten null Accountables. Contributors skalieren; Accountability nicht.

Umsetzung in 45 Tagen

Dieser Einstieg ist kein Kalenderzwang 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 Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Argonos Governance
• Lernpfad — Argonos Governance

Starte mit dem kleinsten 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: Product Record und Mapping

Ein Decision-Produkt wählen, Product Identifier festlegen, Owner/Steward/Stellvertretung benennen, Spaces und Support-Konten dem Record zuordnen. Orphans sichtbar machen.

Schritt 2: Entscheidungsrechte schärfen

Authority-Matrix für die fünf Verantwortung-Zweckbereichs des Piloten füllen. Change-Pfad intern vs. Support schriftlich trennen. Offene Konflikte nicht glätten.

Schritt 3: Recert und Change testen

Einen echten Change mit Owner-Freigabe durchspielen. Einen Support-Pfad mit Zeitfenster und Audit prüfen. Owner- und Privileged-Recert terminieren und einmal durchführen.

Schritt 4: Lücken schließen oder akzeptieren

Fehlende Consumer Owner, Orphan-Spaces und dauerhafte Support-Zugänge in Controls oder Ausnahmen mit Ablauf überführen. Erst dann auf das nächste Produkt ausdehnen.

Messung

• Anteil kritischer Decision-Produkte mit namentlichem Owner, Steward und Stellvertretung
• Anteil der Spaces/Projekte mit gültigem Product-Record-Mapping
• Anteil der Changes mit dokumentierter Freigabe durch die verantwortliche Person
• Anteil privilegierter und Support-Konten mit aktuellem Recert
• Zeit bis zur Klärung „wer entscheidet Zweck/Risiko?“ durch eine unbeteiligte Person
• Anzahl offener Verantwortung-Konflikte älter als ein Review-Zyklus

Checkliste

• Product Identifier ist stabil und außerhalb der UI geführt.
• Data Owner und Steward sind namentlich, erreichbar und mit Stellvertretung versehen.
• Platform- und Dienstleister-Admins sind als Contributors geführt, nicht als Accountables.
• Jeder produktrelevante Space ist einem Product Record zugeordnet.
• Change-Pfad trennt Antrag, Freigabe und Umsetzung (intern vs. Support).
• Change ohne Freigabe durch die verantwortliche Person ist unmöglich oder Ausnahme mit Expiry.
• Nutzer verantwortliche Person sind benannt; bekannte Übergaben haben Genehmiger.
• Recert-Datum für Owner und Privileged/Support Access ist gesetzt.
• Authority-Matrix deckt Purpose, Verantwortung, Access-Freigabe und Ausnahmen ab.
• Supportzugänge haben Zweck, Zeitfenster und Audit-Erwartung.
• Orphan-Spaces und geteilte Accountability sind als Findings geführt.
• Review-Termin für Product Record und Rollenmapping ist gesetzt.

Artefakt

Das Ergebnis ist ein Verantwortung Operating Pack pro Decision-Produkt: Product Record (versioniert), Space-/Project-Mapping, Authority-Ausschnitt für Verantwortung-Zweckbereichs, Change-Pfad inkl. Support, Recert-Plan und Liste offener Konflikte mit Owner und Frist.

Ergänzt wird er durch ein kurzes Contributor-Register für Plattform-, Vendor- und Delivery-Zugänge. Das Register verhindert, dass Umsetzungsmacht stillschweigend als Verantwortung gelesen wird.

Der Pack ist Betriebsvertrag. Owner-Wechsel, Deployment-Wechsel oder neue Support-Verträge erzeugen eine neue Version und lösen Recert sowie gezielte Access-Nachtests aus.

Werkzeuge und Referenzen

• Authority Matrix Builder
• Access Recertification Checklist
• Pillar Gap Quick Check
• Argonos als Betriebsgrenze
• Argonos als Governance-Einstieg
• Data Verantwortung & Stewardship
• Die 8 Säulen der Data Governance
• Palantir und Argonos — Vergleich
• Governance über mehrere Plattformen
• Host vs Cloud