Governance über Funktionen hinweg — Nachfrage, gemeinsame KPIs und Domain-Grenzen

Sales meldet Closed Won, Finance bucht Umsatz erst bei Rechnung, Marketing rechnet denselben Deal der Kampagne zu — drei Wahrheiten für eine Entscheidung. Die schwierigsten Governance-Fragen liegen an diesen Funktionsgrenzen. Die Landkarte, warum Fachbereich und Grenze zur These gehören: Binom Governance — das Konzept.

Sales nennt einen Deal gewonnen. Finance entscheidet, wann Umsatz entsteht. Marketing beansprucht Kampagnenwirkung. Operations bestätigt Lieferfähigkeit. HR plant Kapazität. Data Engineering verbindet die Signale. IT und Plattform sichern Betrieb und Zugriff.

Jede Funktion kann ihre Daten lokal sauber führen und trotzdem kann die gemeinsame Entscheidung scheitern.

Die Ursache ist häufig keine fehlende Definition innerhalb einer Domain. Es fehlt ein Vertrag an der Grenze:

• Wer liefert welches Signal?; Wer darf es verändern?; Welche gemeinsame Identität verbindet die Produkte?; Welcher Zeitpunkt ist verbindlich?; Wer entscheidet bei Konflikt?; Welche Abweichung wird eskaliert?

Funktionsübergreifende Governance zentralisiert nicht jede Definition. Sie macht Grenzen, Übergaben und Konfliktentscheidungen verbindlich.

Produkte und Entscheidungen

Shared-Identity-Produkt

Gemeinsame Prozesse benötigen verbindende Identitäten.

Typische Beispiele:

• Customer und Account;
• Employee und Position;
• Product und Material;
• Supplier;
• Vereinbarung;
• Location;
• Cost Center;
• Campaign;
• Order.

Der Contract enthält:

• globale oder föderierte ID; Quellsystem; Match-Regel; Hierarchie; Gültigkeit; Merge und Split; Domain Owner; Mapping verantwortliche Person.

Nicht jede Domain braucht dasselbe Modell. Sie braucht aber einen kontrollierten Übergang.

Shared-KPI-Produkt

Eine gemeinsame KPI benötigt:

• Entscheidungszweck; Formel; Komponenten; fachliche Ebene; Zeitbezug; Umfang; Ausschlüsse; Quellprodukte; verantwortliche Person; Steward; Version; Abgleich.

Shared bedeutet nicht, dass ein zentraler Ausschuss jedes Detail besitzt.

Eine Domain kann Komponenten verantworten. Genau eine accountable Instanz verantwortet die veröffentlichte KPI-Version.

Demand-Intake-Produkt

Demand ist selbst ein governter Flow.

Ein guter Intake erfasst:

• gewünschte Entscheidung; Nutzer; benötigte Grundgesamtheit; erwarteten Nutzen; Frist; betroffene Domains; Sensitivität; vorhandene Produkte; Sponsor; Erfolgskriterium.

Der Intake darf nicht mit einer Wunschliste von Tabellen beginnen.

Cross-Domain-Contract

Ein Grenze Contract beschreibt:

• liefernde Domain; empfangende Domain; Interface; Semantik; fachliche Ebene; Schlüssel; Aktualität; Quality; Change Notice; Incident-Pfad; Kosten- oder Kapazitätsgrenze.

Escalation-Produkt

Eskalation ist kein persönliches Scheitern.

Sie ist ein definierter Service für Konflikte, die innerhalb einer Domain nicht lösbar sind.

Der Contract benötigt:

• Trigger; Dringlichkeit; erforderliche Evidenz; accountable Instanz; Quorum; Entscheidungsfrist; Vertretung; dokumentiertes Ergebnis; Reopen-Regel.

Domain-Grenzen schneiden

Nach Entscheidungen, nicht Systemen

Ein CRM ist keine Domain. Ein ERP ist keine Domain. Ein Warehouse ist keine Domain.

Systeme implementieren mehrere Verantwortungsbereiche. Domain-Grenzen sollten an stabilen fachlichen Entscheidungen orientiert sein.

Source-aligned und Consumer-aligned trennen

Ein Source-aligned Product repräsentiert einen verantworteten operativen Zustand.

Ein Consumer-aligned Product kombiniert Quellen für eine konkrete Nutzung.

Beide können legitim sein. Ihre Owner und Change-Rechte unterscheiden sich.

Gemeinsame Entitäten föderieren

Customer kann in Marketing, Sales, Service und Finance unterschiedliche Attribute tragen.

Eine sinnvolle Aufteilung ist:

• gemeinsame Identität und Hierarchie;
• domain-eigene Zustände;
• kontrollierte Mappings;
• explizite Nutzungssichten.

Ein gigantisches Golden Record mit allen Attributen erzeugt häufig neue Konflikte.

Grenze Owner benennen

Jede Seite einer kritischen Übergabe braucht eine verantwortliche Kontaktstelle.

Der liefernde Owner verantwortet den angebotenen Contract.

Der empfangende Product Owner verantwortet die korrekte Integration und Nutzung.

Demand steuern

Bedarf qualifizieren

Vor Priorisierung werden fünf Fragen beantwortet:

1. Welche Entscheidung wird besser?
2. Wer nutzt das Ergebnis?
3. Welches bestehende Produkt deckt den Bedarf teilweise?
4. Welche Domain-Entscheidung fehlt?
5. Woran wird Nutzen nach Veröffentlichung erkannt?

Nachfrage bündeln

Mehrere Tickets können dasselbe strukturelle Problem beschreiben.

Stewards und Product Owner bündeln:

• wiederkehrende Definitionsfragen;
• fehlende Dimensionen;
• Quality-Lücken;
• neue Nutzer;
• manuelle Reconciliations;
• lokale Exporte.

Priorisierung transparent machen

Geeignete Kriterien sind:

• Entscheidungswert; Risiko; Anzahl betroffener Nutzer; regulatorische Frist; Wiederverwendung; Aufwand; Abhängigkeiten; Reversibilität.

Ein lauter Sponsor ist kein objektives Prioritätskriterium.

Ablehnung als Ergebnis

Governance darf Anforderungen ablehnen.

Eine gute Ablehnung nennt:

• Grund;
• vorhandene Alternative;
• fehlende Voraussetzung;
• Reopen-Bedingung;
• verantwortliche Entscheidung.

Gemeinsame KPIs

Komponenten-Verantwortung

Bei einer Kennzahl wie Customer Acquisition Cost verantwortet Marketing Kampagnenkosten und Demand-Signale. Finance verantwortet Kostenbehandlung. Sales verantwortet Opportunity- und Abschlussstatus.

Die KPI selbst braucht eine veröffentlichende accountable Instanz.

Zeit und Version

Gemeinsame KPIs scheitern häufig an Kalendern, Stichtagen und rückwirkenden Änderungen.

Der Vertrag muss festlegen:

• Event Time;
• Processing Time;
• Reporting Period;
• Restatement;
• Freeze;
• Version;
• Gültigkeit.

Reconciliation statt erzwungener Gleichheit

Sales Revenue, recognized Revenue und Marketing-attribuierter Revenue dürfen unterschiedlich sein.

Governance verlangt:

• klare Namen;
• erklärte Brücken;
• bekannte Abweichungen;
• abgestimmte Übergabeschlüssel;
• passende Nutzung.

Sie verlangt nicht, unterschiedliche Konzepte künstlich gleichzusetzen.

Eskalation gestalten

Wann eskalieren

• zwei verantwortliche Person beanspruchen dieselbe Entscheidung;
• kein verantwortliche Person akzeptiert eine Grenze;
• ein Vereinbarung verletzt eine andere Domain;
• eine gemeinsame KPI bleibt widersprüchlich;
• Frist oder Risiko überschreitet Domain-Mandat;
• wiederholte Ausnahme wird strukturell;
• Prioritäten blockieren einen kritischen Flow.

Wohin eskalieren

Die Eskalationsstufe folgt der Entscheidung.

Beispiele:

• Domain Owner für lokale Semantik;
• Product Council für Portfolio-Konflikte;
• Architecture Forum für Interface-Grenzen;
• Risk oder Privacy für Richtlinie-Auslegung;
• Executive Sponsor für unauflösbare Zielkonflikte.

Was eine Entscheidung enthalten muss

• Frage; Optionen; Evidenz; Betroffene; Entscheidung; accountable Person; Gültigkeit; Umsetzungsowner; Review-Datum.

Ein Meeting-Protokoll ohne Entscheidung ist keine Governance-Evidenz.

Rollen-Mapping

Data Owner

Owner bleiben in ihren Domains accountable.

Für eine gemeinsame KPI wird ein Lead Owner benannt. Andere Owner liefern verpflichtende Komponentenentscheidungen.

Data Steward

Stewards verbinden Begriffe, Issues und Evidenz über Grenzen.

Ein Lead Steward koordiniert. Er überschreibt keine Domain-Entscheidung.

Data Product Owner

Product Owner koordinieren Backlogs, Releases und Deprecation abhängiger Produkte.

Sie machen Cross-Domain-Arbeit als Kapazität sichtbar.

Data Architect

Architects schützen Identitäten, Grain, Interfaces und Versionierung.

Sie moderieren technische Optionen, besitzen aber nicht automatisch fachliche Zielkonflikte.

Data Custodian

Custodians setzen Zugriff, Betrieb, Logging und Recovery über Plattformen hinweg um.

Sie benötigen klare fachliche Freigaben.

Data Consumer

Consumer formulieren Entscheidung und Nutzung.

Sie dürfen Unterschiede nicht durch private Joins oder lokale KPI-Definitionen verdecken.

SMB versus Enterprise

SMB

Ein SMB braucht kein großes Data Council.

Praktisch reichen:

• ein gemeinsamer Anfrageweg;
• fünf bis zehn kritische Produkte;
• drei Shared KPIs;
• benannte verantwortliche Person;
• wöchentlicher Triage-Slot;
• monatlicher Konflikt-Slot;
• ein Decision Log.

Mehrfachhüte bleiben sichtbar.

Enterprise

Ein Enterprise benötigt gestufte Föderation.

Domain-Ebene:

• Produkt- und Begriffsentscheidungen; Quality Issues; lokale Priorisierung.

Cross-Domain-Ebene:

• Identitäten; Grenze Vereinbarungen; Shared KPIs; gemeinsame Roadmaps.

Enterprise-Ebene:

• Richtlinien; strategische Konflikte; Investitionsgrenzen; konzernweite Standards.

Fälle sollen auf der niedrigsten wirksamen Ebene entschieden werden.

Anti-Patterns

Zentrales Team besitzt alle Begriffe

Kontext und Entscheidungskapazität werden vom operativen Geschäft getrennt.

Jede Meinungsverschiedenheit ins Council

Gremien werden zum Ticket-Router.

Shared KPI ohne Lead Owner

Viele Beteiligte bedeuten dann keine Accountability.

Enterprise Customer als Universalmodell

Ein überladenes Modell ersetzt keine kontrollierten Domain-Sichten.

Demand nach Sponsorlautstärke

Wert, Risiko und Wiederverwendung bleiben unsichtbar.

Eskalation ohne Frist

Offene Konflikte wandern in Schattenlogik.

Einheitliche Zahlen erzwingen

Unterschiedliche fachliche Konzepte werden unbrauchbar vermischt.

Platform Owner als Konfliktentscheider

Technische Nähe ersetzt kein fachliches Mandat.

Cross-Domain-Arbeit nebenbei

Ohne Backlog und Kapazität bleiben Übergaben dauerhaft fragil.

Mini-Scorecard

Bewerte jede Aussage mit 0, 1 oder 2 Punkten.

Grenzen

• Domains sind nach Entscheidungen geschnitten.
• gemeinsame Identitäten besitzen Vereinbarungen.
• Grenze verantwortliche Person sind benannt.

Nachfrage

• Anfrageweg beginnt mit einer Entscheidung.
• Priorisierung nutzt transparente Kriterien.
• Ablehnungen sind nachvollziehbar.

Gemeinsame Produkte

• Shared KPIs haben einen Lead verantwortliche Person.
• Komponenten und Versionen sind sichtbar.
• Abweichungen werden reconciliiert.

Eskalation

• Trigger und Stufen sind definiert.
• Entscheidungen besitzen Frist und Evidenz.
• Umsetzungen werden nachverfolgt.

0–7 Punkte: lokale Governance mit unsichtbaren Grenzkonflikten.

8–16 Punkte: arbeitsfähige Domains mit schwachen Übergaben.

17–24 Punkte: föderierte, entscheidungsfähige Cross-Functional Governance.

Erster Umsetzungsschnitt

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 — Governance Foundations
• Lernpfad — Governance Foundations

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.

Woche 1

• eine kritische gemeinsame KPI wählen;
• beteiligte Produkte und verantwortliche Person markieren;
• Definitionen und Zeitbezüge vergleichen.

Woche 2

• Grenze Vereinbarungen skizzieren;
• Demand Anfrageweg auf Entscheidungen umstellen;
• Eskalationstrigger festlegen.

Woche 3

• einen realen Konflikt durch den Flow führen;
• Abgleich und Change Notice testen;
• Cross-Domain-Kapazität im Backlog reservieren.

Woche 4

• Wartezeit und Rückläufer messen;
• ein unnötiges Gremium entfernen;
• drei offene Entscheidungen schließen;
• Decision Log veröffentlichen.

Fachbereich-Operating-Serien

• Sales-Landschaft
• Finance-Landschaft
• HR-Landschaft
• Marketing-Landschaft
• Operations-Landschaft
• Partnerlandschaften
• Korridor für Folgeprojekte

Der nächste Teil reduziert das Modell auf ein Minimum für kleine Organisationen: genug Governance für verlässliche Entscheidungen, ohne aufgeblasenes Enterprise-Programm.