Lanes und Delegation für Governance-Projekte
Wer bei Governance-as-a-Service wofür gerufen wird: Sales erkennt das Problem, Delivery liefert den vereinbarten Ausschnitt, Fachbereiche behalten fachliche Verantwortung.
Der vorherige Artikel klärt, wie Governance als Dienstleistung verkauft wird. Dieser Artikel klärt, wer danach gerufen wird.
Sales muss Governance nicht technisch bauen. Sales muss erkennen, welches Problem beim Kunden sichtbar wird, welchen Ausschnitt man anbieten kann und welche Delivery-Lane gebraucht wird. Eine Lane ist hier eine Ausführungsspur mit eigener Kompetenz, zum Beispiel Governance-Beratung, Data Engineering, Plattform, BI oder Datenschutz.
Ausgangslage
Ein Auftrag startet mit einem verständlichen Kundenproblem: Ein Forecast ist nicht verlässlich, ein Reporting ist nicht auditfähig, ein sensibler Datensatz darf nicht unkontrolliert in die Cloud, oder ein Fachbereich kennt seinen Daten-Owner nicht. Danach wird es unscharf. Sales spricht mit BI, BI zeigt auf das Warehouse, das Warehouse zeigt auf Data Engineering, Data Engineering zeigt auf den Fachbereich, und am Ende fühlt sich niemand zuständig.
Das Problem ist nicht fehlender Wille. Es fehlt eine Delegationslogik: Wer erkennt, wer entscheidet, wer setzt technisch um, wer prüft Nachweise, und wer sagt Stopp, wenn der Auftrag zu breit wird?
Begriffe vor dem Lesen
- Lane ist eine Ausführungsspur mit klarer Verantwortung im Projekt, zum Beispiel Governance, Plattform, Data Engineering, BI, Datenschutz oder Fachbereich.
- Delegation bedeutet: Eine Aufgabe wird an die richtige Lane übergeben, inklusive Kontext, Erwartung und Grenze.
- Fachliche Verantwortung bleibt beim Fachbereich oder bei der Rolle, die die Bedeutung verantwortet. Eine Plattform-Lane kann Zugriff durchsetzen, aber nicht definieren, was "gebuchter Umsatz" bedeutet.
- Technische Umsetzung ist die konkrete Realisierung in Systemen, Pipelines, Berechtigungen, Tests oder Reports.
- Nachweis ist ein prüfbarer Nachweis, dass eine Regel eingehalten wurde.
- Stopp-Regel ist die bewusste Grenze: Wenn verantwortliche Person, Zweck, Nachweis oder Voraussetzung fehlen, wird der Umfang nicht still erweitert.
Grundregel
Sales erkennt und strukturiert. Delivery liefert. Der Fachbereich entscheidet die Bedeutung.
Das klingt einfach, verhindert aber viele politische Reibereien. Governance wird nicht zum Herrschaftsanspruch einer zentralen Stelle. Sie wird zur Hausordnung: gemeinsame Regeln, lokale Umsetzung, fachliche Verantwortung dort, wo das Wissen sitzt.
Delegationskarte
| Signal im Kundengespräch | Richtige Lane | Warum | Sales sollte nicht |
|---|---|---|---|
| "Unsere Kennzahl stimmt in jedem Dashboard anders." | Governance + BI/Metrics | Bedeutung, Formel und Consumer müssen zusammengebracht werden. | ein weiteres Dashboard versprechen |
| "Wer darf diese Kundendaten sehen?" | Datenschutz + Plattform + Fachbereich | Zweck, Rechtsgrundlage, Rollen und technische Durchsetzung gehören zusammen. | Zugriff allein als Tool-Setting behandeln |
| "Unsere Pipeline ist unzuverlässig." | Fachbereich Sales + Governance + BI | Stage-Bedeutung, Forecast-Snapshot und Handoff müssen geklärt werden. | CRM-Pflichtfelder ohne Verbraucher zusagen |
| "Der Mart ist technisch grün, aber fachlich falsch." | Data Engineering + Fachbereich | Tests und Pipeline-Gates brauchen fachliche Regeln. | Engineers zum Owner der Bedeutung machen |
| "Audit will Nachweise sehen." | Governance + Compliance + Plattform | Evidence braucht Prozess, Regel und Systemnachweis. | Folien als Nachweis verkaufen |
| "Wir dürfen nicht jedes SaaS nutzen." | IT/Security + Datenschutz + Plattform | Betrieb, Datenresidenz und Vertragsgrenzen müssen vor Toolnutzung klar sein. | Standard-Cloud als Normalfall annehmen |
Lane-Verträge
Governance-Lane
Aufgabe: Problem, Owner, Regel, Review und Evidence zusammenführen.
Typische Ergebnisse:
- Governance-Umfang;
- Entscheidung über fachliche Verantwortung und Rollen;
- KPI-, Access-, Datenprodukt- oder Handoff-Vertrag;
- Review-Rhythmus;
- Nachweis-Register.
Nicht Aufgabe: Plattform administrieren, Datenmodell ohne Fachbereich definieren, Datenschutz ersetzen.
Fachbereichs-Lane
Aufgabe: Bedeutung und Entscheidung verantworten.
Typische Ergebnisse:
- klare Entscheidungsfrage;
- Definition von Kennzahl, Status, Produkt oder Prozessschritt;
- benannter verantwortliche Person;
- fachliche Abnahme.
Nicht Aufgabe: technische Sicherheitsarchitektur bauen oder allein unternehmensweite Standards festlegen.
Data-Engineering-Lane
Aufgabe: Datenflüsse, Transformationen, Tests und technische Gates umsetzen.
Typische Ergebnisse:
- Pipeline-Vertrag;
- Datenqualitätsregeln;
- Breaking-Change-Regel;
- nachvollziehbare Verarbeitung;
- Testnachweise.
Nicht Aufgabe: fachliche Bedeutung erfinden.
Plattform-Lane
Aufgabe: technische Durchsetzung in Systemen wie Warehouse, Lakehouse, Catalog, IAM, Ranger, Unity Catalog oder Fabric.
Typische Ergebnisse:
- Berechtigungsregel;
- Klassifikation;
- Richtlinie;
- Audit-Log;
- Betriebsgrenze.
Nicht Aufgabe: fachlicher Owner sein, nur weil die Plattform die Regel durchsetzt.
BI- und Metrics-Lane
Aufgabe: Kennzahlen, semantische Schicht, Reports und Consumer-Entscheidungen konsistent machen.
Typische Ergebnisse:
- KPI-Karte;
- semantische Definition;
- Publish-Regel;
- Report-Abnahme;
- Nutzer-Feedback.
Nicht Aufgabe: fehlende Quellverantwortung kaschieren.
Datenschutz-, Legal- und Compliance-Lane
Aufgabe: rechtliche, regulatorische und kontrollbezogene Anforderungen einordnen.
Typische Ergebnisse:
- Zweck und Rechtsgrundlage;
- Risiko- und Schutzbedarf;
- Aufbewahrung und Löschung;
- Kontrollnachweise;
- Freigabe- oder Eskalationsweg.
Nicht Aufgabe: operative Fachentscheidung übernehmen.
Stopp-Regeln
Ein guter Governance-Auftrag darf kleiner werden. Manchmal muss er sogar kleiner werden.
Stopp ist richtig, wenn:
- keine fachlich verantwortliche Person benannt werden kann;
- der Kunde keine Entscheidung oder Kennzahl nennen kann;
- Datenschutz, Security oder Audit als "später" behandelt werden, obwohl sie den Umfang bestimmen;
- technische Umsetzung verkauft werden soll, aber die fachliche Regel fehlt;
- ein Tool als Ersatz für Verantwortung dienen soll;
- ein 90-Tage-Slice heimlich zur kompletten Transformation wird.
Stopp heisst nicht: kein Projekt. Stopp heisst: erst klären, dann liefern.
Handoff von Sales an Delivery
Sales übergibt nicht "Governance". Sales übergibt einen konkreten Auftrag.
Minimum für das Handoff:
- Kundenproblem in einem Satz;
- betroffene Entscheidung oder Kennzahl;
- Kunde, verantwortliche Person oder Lücke in der fachlichen Verantwortung;
- vereinbarter Leistungsumfang;
- ausgeschlossener Umfang;
- benötigte Lane;
- erwartete Nachweis;
- nächster Termin.
Fehlt eines davon, ist der Auftrag noch nicht delivery-reif.
Beispiel
Ein Versicherer möchte ein neues Reporting für Schadensquote und Reserven bauen. Im Gespräch wird klar: Die Kennzahl ist regulatorisch relevant, Aktuariat und Finance nutzen unterschiedliche Logik, und das Data-Warehouse-Team kann nur technische Tabellen liefern.
Saubere Delegation:
- Fachbereich: Aktuariat und Finance klären Bedeutung und Entscheidungszweck.
- Governance-Lane: macht daraus KPI-Vertrag, Rollen, Review und Nachweis.
- Data Engineering: setzt fachliche Zählebene, Tests und Verarbeitung um.
- Plattform: setzt Zugriff und Audit-Logs um.
- Compliance: prüft Nachweis- und Aufbewahrungsanforderungen.
Unsauber wäre: Sales verspricht "ein neues Dashboard mit Governance", und Delivery muss später erraten, wer die Definition verantwortet.
Lesepfad
- Governance als Dienstleistung verkaufen
- Lanes und Delegation für Governance-Projekte
- Welche Artefakte entstehen?
Selling governance as a service
Part 2 of 5
View series