Operating Contracts — von Hub-Intros zu durchsetzbaren Vereinbarungen

Ein durchgängiger Arbeitsfall für diese Serie

Ein Datenprodukt betrifft einen Rechtsfall, eine Risikokennzahl, ein Serviceticket, einen Dienstleister und vertrauliche Entwicklungsunterlagen. Die fünf Prüfungen dürfen gemeinsam dokumentiert werden, ihre Entscheidungen bleiben aber bei den jeweils zuständigen Rollen. Ein grüner Sammelstatus ersetzt keinen fehlenden Einzelentscheid.

Die Beispieldaten sind erfunden. Die beschriebenen Prüfungen werden erst durch eigene Ausführung und dokumentiertes Ergebnis zu einem Betriebsnachweis.

Ergebnis des begrenzten Auftrags: Jede betroffene Funktion bestätigt ihre Entscheidung, deren Umfang und verbleibende Bedingungen. Die technische Umsetzung zeigt das erwartete Verhalten auch im Fehlerfall.

Wirtschaftlichen Nutzen prüfen: Miss wiederholte Nachweissuche und Abstimmung derselben Bedingungen. Erforderliche Fachprüfungen bleiben bestehen; die Entlastung entsteht durch klare Übergaben und wiederverwendbare gültige Entscheidungen.

Für Microsoft 365 beschreibt Microsoft das Verwalten von Holds und die Priorität von Aufbewahrung und Holds. Die Probe unten ist ein organisationsbezogenes Entscheidungsmuster; konkrete Rechtsgrundlagen, Zuständigkeiten und technische Abläufe werden für den eigenen Bestand geprüft.

Begriffe vor dem Lesen

• Operating Contract / betriebliche Vereinbarung — festgelegte Verantwortung, fachliche Zählebene, Kontrollregel, Nachweisort und Ausnahmeweg für ein wichtiges Daten- oder Prozessprodukt.
• Legal Hold — rechtliche Sperre: bestimmte Akten, Kopien oder Ableitungen dürfen während eines Rechtsfalls nicht gelöscht oder überschrieben werden.
• Retention — geplanter Lebenszyklus: wie lange Daten regulär aufbewahrt und wann sie gelöscht werden.
• Risikokennzahl / Key Risk Indicator (KRI) — Kennzahl, die ein Risiko beobachtet, zum Beispiel offene kritische Fälle. Sie braucht eine klare fachliche Zählebene.
• Ticket↔Party-Zuordnung — Verbindung zwischen einem Service-Ticket und einer Person, Organisation oder einem Account. Sie ist nur mit klarem Zweck erlaubt.
• Dienstleister-Nachweis — prüfbarer Nachweis vor Datenzugang, zum Beispiel Assessment, Datenschutzvertrag, Subprocessor-Liste und Ausstiegsregel.
• R&D-IP-Grenze — Grenze für geistiges Eigentum in Research und Produktentwicklung: welche Designs, Rezepte, Code-Objekte oder Ideen ein Dienstleister nicht sehen darf.
• fachlich verantwortliche Person — je Funktion die Rolle, die fachlich entscheiden darf: Legal, Risk, Customer Service, Procurement oder R&D. Es gibt keine gemeinsame Zentralrolle, die alle fünf Fachentscheidungen ersetzt.

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Fall-, Ticket-, Vendor- und Toolnamen durch eure Funktions-, Catalog- und Prozessquellen. Lest die fünf Landschaftskarten als Peer-Geltungsbereich, nicht als Kapitel 1–6.

Der Kern

Eine betriebliche Vereinbarung macht eine Landschaftskarte ausführbar. Sie sagt nicht nur “Legal ist beteiligt” oder “Risk braucht Evidenz”, sondern beantwortet: Was genau ist betroffen? Wer entscheidet fachlich? Welche technische Regel setzt es um? Wo liegt der Nachweis? Wie lange gilt eine Ausnahme?

Merksatz: Erst die fachliche Zählebene, die Kontrollregel und der Nachweisort machen Governance im Betrieb belastbar.

Produkte und Entscheidungen

Der Deep Dive braucht nicht „eine Extended-Platform“, sondern geschnittene Produkte. DORA-Meldepacks und Sales-Pipeline gehören in andere Serien.

Mindestfelder je Funktion

Dieses Produkt beschreibt — je Legal, Risk, CS, Procurement, R&D:

• Materielles Produkt; fachlich verantwortliche Person; Steward; technischer Betreiber; fachliche Zählebene; erlaubte Zwecke; Kontrollregel mit Evidenzort; Ausnahmeweg mit Ablauf; Review-Datum.

Entscheidungen:

• Welche drei Produkte sind wichtig genug für den ersten Schnitt? Wer darf ein Hub-Intro ohne diese Felder nicht als freigegeben behandeln? Welche Schatten-Exporte, Tabellen oder inoffiziellen Dienstleisterfreigaben gehören ins Register?

Legal Hold vs. Analytics-Retention

Hold und Retention sind zwei Uhren.

Entscheidungen:

• Welcher Umfang (Akte, Ticket, Ableitung) steht unter Hold?; Wer darf Retention trotz Hold nicht ausführen — Analytics-Admin oder Counsel?; Was passiert am Hold-Release: Löschung nachziehen oder neue Retention?

Risk-Taxonomie und Vereinbarung zur Risikokennzahl

Eine Risikokennzahl ohne fachliche Zählebene ist nur eine Überschrift.

Entscheidungen:

• Welche Taxonomie und welche fachliche Zählebene gelten: Ticket, Incident oder Kunde? Wer darf den Schwellwert ändern: Risk-Verantwortung oder Dashboard-Author? Welche Änderung informiert Customer Service, wenn dieselben Tickets in die Risikokennzahl einfließen?

Customer-Service-Identität und Ticket↔Party

Service erbt nicht still den Marketing-Key.

Entscheidungen:

• Welche fachliche Zählebene trägt die Service-Aussage: Ticket oder Kunde? Welcher Zweck gilt für Zugriff auf Gesprächsnotizen? Wer darf Ticket und Kunde verbinden, und welcher Negativtest verhindert den stillen 360-Export?

Vendor-Nachweis

Onboarding ist keine IP-Freigabe.

Entscheidungen:

• Welcher Nachweis muss vor Datenzugang vorliegen: Assessment, Datenschutzvertrag oder Ausstiegsregel? Wer lehnt den Zugang ab, wenn der Nachweis fehlt?

R&D-IP-Grenze

Derselbe Vendor-Name ist ein zweites Mandat.

Entscheidungen:

• Welche Design- oder Code-Objekte darf R&D demselben Dienstleister nicht geben?; Wer lehnt den Partnerfreigabe ab — Head of R&D, nicht der CPO stellvertretend?

Wo Governance hängt

Zwischen Landschaftskarte und Operating Contract

Die Peer-Karte erklärt die Betriebsgrenze. Ohne Contract-Mindestfelder bleibt sie Intro. Catalog-Vollständigkeit ist Discovery, kein Kontrollregel.

Zwischen Hold-Memo und Lake-Retention

Derselbe Fall unter Hold im Memo und unter sieben Jahren Analytics im Lake ist eine stille Pflichtkollision.

Zwischen Key Risk Indicator (KRI)-Überschrift und Ticket-Ebene

Risk zählt Incidents, CS zählt Tickets. Ohne Contract ist „offen hoch“ eine Folie.

Zwischen Ticket und Party

Ein Service-Export mit Kunden-Key ohne Zweck ist eine Identitätsweitergabe, kein Ticket-Bericht.

Zwischen Procurement-Onboarding und R&D-Share

Der Vendor ist „approved“. Das hebt die IP-Grenze nicht auf. Zwei Owner, zwei Freigaben.

Zwischen Tool-Admin und Function Owner

Wer Hold-Flag, Key Risk Indicator (KRI)-Measure oder Vendor-Gruppe setzen kann, entscheidet damit nicht Geltungsbereich, Schwellwert oder IP-Freigabe.

Rollen-Mapping

Function Owner (fünf Sitze)

General Counsel oder Head of Legal Ops trägt Hold-Geltungsbereich und Policy-Version. CRO oder Head of Risk trägt Taxonomie und Key Risk Indicator (KRI). Head of Customer Service trägt Ticket-Zweck und Party-Join. CPO oder Head of Procurement trägt Vendor-Nachweis. Head of R&D oder Product trägt die IP-Grenze. Kein gemeinsamer „Extended Owner“ ersetzt die fünf Sitze.

Data Steward

Legal Operations, Risk Operations, Service Operations, Procurement Ops oder R&D Ops — je Funktion — triagiert Contract-Lücken, Exception-Abläufe und eskaliert Schatten-Pfade.

Data Product Owner

Priorisiert Contract-Releases und Nachweis Packs. Nutzen und Lieferbarkeit — nicht die Rechts- oder Risikoauslegung.

Data Architect

Schützt fachliche Zählebene (Hold-Geltungsbereich ≠ Retention-Objekt ≠ Ticket ≠ Party ≠ Vendor ≠ IP-Objekt) und Breaking Changes an Funktions-Schnittstellen.

Data Custodian

eDiscovery-, Risk-, Compliance-, Ticketing-, ERP- und PLM-Admin setzen Flags, Jobs, Zugriffsregel und Pausen um. Konfigurationsmacht ist keine fachliche Autorität.

Data Consumer

Analytics, Board-Risk, Supervisor, Vendor, Lab — nur mit Zweck. Abweichungen teilen einen Intake je Funktion.

Mini-Fall

Alltagssituation: Eine Kundenakte darf wegen eines Rechtsfalls nicht gelöscht werden. Analytics behält daraufhin pauschal Kopien für sieben Jahre, ohne zu klären, welche Daten wirklich betroffen sind. Risk zählt „offene kritische Tickets“ anders als Customer Service. Procurement gibt einen Dienstleister frei; R&D teilt Design-Dateien, ohne festzulegen, welche Ideen, Zeichnungen oder Schutzrechte das Unternehmen verlassen dürfen.

Was schiefläuft: Jede Funktion hat einen nachvollziehbaren Teil der Wahrheit, aber keine gemeinsame Betriebsvereinbarung. Ein Tool oder Katalog-Tag klärt nicht, welche Löschung gesperrt ist, wie die Risikozahl gezählt wird, welches Ticket zu welcher Person gehört oder wer einen R&D-Share ablehnen darf.

Vereinbarung: Hold-Umfang mit wirksamer Sperre gegen Analytics-Löschung; Vereinbarung zur Risikokennzahl auf Ticket-Ebene mit CRO als verantwortlicher Person; Service-Zweck am Ticket; Dienstleister-Nachweispaket vor Zugang; R&D-IP-Grenze, die denselben Dienstleisterfreigabe ablehnen kann. Die Landschaftskarten bleiben Peer-Umfang, keine Sequenz.

Kritische Übergaben

Typische Fehlmuster

• Catalog-Vollständigkeit oder Hub-Intro mit Governance verwechseln
• Die fünf Funktionen als Legal→Procurement-Lernsequenz behandeln
• technisch verantwortliche Person statt fachlich verantwortliche Person als Entscheidungsinstanz einsetzen
• Hold und Analytics-Retention in einer Uhr mischen
• Key Risk Indicator (Risikokennzahl) ohne fachliche Zählebene als Board-Zahl liefern
• Ticket und Party ohne Zweck joinen
• Dienstleister „approved“ als IP-Freigabe lesen
• Ausnahmen ohne Ablaufdatum und ohne fachlich verantwortliche Person

Umsetzung im Alltag

Schritt 1: Rahmen und Entscheidung klären

Wähle eine Funktion und einen echten Bruch aus der jüngeren Vergangenheit: eine rechtliche Sperre gegen Analytics-Kopien, eine Risikokennzahl gegen Service-Tickets oder eine Dienstleisterfreigabe gegen R&D-IP-Grenzen. Benenne drei wichtige Produkte mit fachlich verantwortlicher Person, Steward und technischem Betreiber. Prüfe, welche Mindestfelder im Hub-Intro fehlen.

Schritt 2: Kontrollregel und Nachweis umsetzen

Setze eine wirksame Regel produktiv: zum Beispiel eine Löschsperre für betroffene Akten, eine Risikokennzahl mit klarer Zählebene oder Dienstleisterzugang erst nach Nachweis. Dokumentiere eine Ausnahme mit Grund, Ablaufdatum und fachlicher Freigabe. Verlinke den Catalog auf die Vereinbarung; pflege die Kontrolle nicht nur als Catalog-Text.

Schritt 3: Testen und Ausnahmen sichtbar machen

Teste bewusst den Fehlerfall: Eine Analytics-Löschung trotz Legal Hold, eine Risikokennzahl ohne klare Zählebene oder eine R&D-Freigabe ohne IP-Entscheidung muss stoppen oder eskalieren. Danach muss nachvollziehbar sein, wo der Nachweis lag und wer entschieden hat. Einen entdeckten Schattenpfad holst du nachträglich ins Register.

Schritt 4: Messen und begrenzt ausrollen

Miss Aufwand und Lücken. Übertrage nur bewährte Muster auf eine zweite gleichrangige Funktion: Mindestfelder, eine wirksame Sperre oder Regel, Ausnahme mit Ablaufdatum. Das ist kein Abarbeiten einer Reihenfolge, sondern kontrolliertes Ausweiten eines funktionierenden Musters.

Exit-Kriterien

• Jedes materielle Funktionsprodukt hat verantwortliche Person, fachliche Zählebene, Kontrollregel, Evidenzort und Ausnahmeweg.
• Die fünf fachlich verantwortlichen Personen sind benannt; Tool-Admin ist technischer Betreiber.
• Legal Hold und Retention sind getrennt; die Risikokennzahl hat eine fachliche Zählebene; Ticket↔Party hat einen Zweck; Dienstleister-Nachweis und IP-Grenze sind zwei Freigaben.
• Die Serie ist als Deep Dive zur Peer-Landschaft schriftlich abgegrenzt — keine Legal-erste Rangfolge.
• Der technische Betreiber liefert Konfigurationsnachweis und bestandenen Negativtest am gewählten Bruch.

Weiterlesen

• Extended Function Landscape — gleichrangige Funktionsübersicht, keine Vertiefungssequenz
• Governance in Legal und Compliance
• Governance in Risk
• Governance in Customer Service
• Governance in Procurement
• Governance in R&D / Product

Den Arbeitsfall in diesem Kapitel prüfen

Zerlege den Fallverbund in fünf verantwortete Entscheidungen: Aufbewahrung, Risikoauswertung, Serviceidentität, Dienstleisterzugang und Entwicklungsgeheimnis. Verknüpfe sie über die betroffene Produktreferenz, statt eine Zentralfreigabe für alles zu erzeugen.

Gegenprobe und Abnahme: Eine offene zwingende Bedingung begrenzt die betroffene Nutzung. Ein grüner Status in einer anderen Funktion hebt sie nicht auf.

Halte erwartetes Ergebnis, tatsächlich beobachteten Stand, Abweichung und zuständige Entscheidung in der Arbeitsakte fest. Ein noch nicht ausgeführter Test bleibt offen.

Arbeitsakte für diese Serie herunterladen · Beispieldaten und Sollwerte

Anschluss für die nächste offene Aufgabe: Legal Hold vs. Analytics-Retention. Übernimm den geprüften Stand und die offenen Bedingungen; zusätzliche Themen bekommen einen eigenen Auftrag.