Operating Models: zentralisiert, föderiert, hub-and-spoke

Die 200-Mio.-Dollar-Reorg, die zweimal scheiterte

2019 zentralisierte ein globaler Konsumgüterkonzern, den wir Meridian nennen, seine Datenfunktion. Jeder Analyst, jede pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen →, jede Governance-Entscheidung lief bei einer einzigen CDO-Organisation mit 400 Personen zusammen. Achtzehn Monate später rebellierten die Business Units: Die Lieferzeiten für neue dashboards waren von Tagen auf Quartale gestiegen, und die kommerziellen Teams hatten im Marketing still und leise Schatten-Analytics-Teams aufgebaut. Also schlug Meridian das Pendel in die andere Richtung: volle Föderation, Datenleute in jeder Einheit eingebettet, minimale zentrale Kontrolle. Innerhalb eines Jahres hatten sie elf inkompatible Definitionen von „aktivem Kunden“, drei sich überlappende Customer Data Platforms und eine Aufsichtsbehörde, die fragte, warum Consent-Daten nicht über Regionen hinweg abgeglichen werden konnten.

Die Lehre ist nicht, dass Meridian zweimal falsch gewählt hat. Sie ist, dass Meridian das Operating Model als Binärschalter behandelt hat, während es tatsächlich ein Portfolio von Entscheidungen darüber ist, wo bestimmte Rechte liegen. Diese Lektion gibt Ihnen die Entscheidungsarchitektur, um es beim ersten Mal richtig zu machen und zu erkennen, wann Sie es weiterentwickeln müssen.

Die eigentliche Variable sind Entscheidungsrechte, nicht Organigramme

Die meisten CDOs formulieren die Operating-Model-Frage als „Wem berichten die Leute?“. Das ist die falsche erste Frage. Das Organigramm ist nachgelagert. Die vorgelagerte Frage lautet: Wer hält für jede Datenaktivität das Entscheidungsrecht, und wer ist für das Ergebnis verantwortlich?

Zerlegen Sie Ihre Datenfunktion in einzelne Aktivitäten und fragen Sie, wo jede angesiedelt sein sollte. Eine brauchbare Zerlegung:

• Plattform und Infrastruktur (das LakehouseLakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.Vollständige Definition ansehen →, Ingestion, Compute-Governance)
• Datenmodellierung und Definitionen (was „Umsatz“ bedeutet, Stammdaten)
• Governance, Datenschutz und Policy (Klassifizierung, Zugriff, Aufbewahrung)
• Analytics und Data Science (Modelle, dashboards, Generierung von insights)
• Entwicklung von Data Products (wiederverwendbare Datenassets mit Eigentümer und SLAs)

Die drei kanonischen Operating Models sind im Grunde nur drei *Standard*-Antworten darauf, wie sich diese Aktivitäten verteilen:

| Aktivität | Zentralisiert | Föderiert | Hub-and-Spoke |

|---|---|---|---|

| Plattform/Infra | Zentral | Zentral (meist) | Hub |

| Definitionen/MDMMDMMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.Vollständige Definition ansehen → | Zentral | Lokal | Hub setzt Standard, Spoke wendet an |

| Governance/Policy | Zentral | Lokal (riskant) | Hub besitzt, Spoke führt aus |

| Analytics/DS | Zentral | Lokal | Spoke (nah am Business) |

| Data Products | Zentral | Lokal | Geteilt |

Lesen Sie die Hub-and-Spoke-Spalte genau. Es ist kein Kompromiss, sondern eine bewusste Teilung: Standards und Plattform zentralisieren, Ausführung und insight verteilen. Deshalb ist es das dominante Muster für große Unternehmen geworden, und deshalb ist die „Data MeshData MeshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.Vollständige Definition ansehen →“-Debatte der Branche im Kern ein Hub-and-Spoke-Argument mit besserem tooling.

Zentralisiert: Argumente dafür und dagegen

Zentralisierung bringt Ihnen Konsistenz, Skaleneffekte und eine einzige Stelle, die bei Compliance zur Verantwortung gezogen werden kann. Ein Team, eine Plattform, eine Definition jeder Metrik. Für ein Unternehmen mit weniger als rund 2.000 Mitarbeitern oder mit einer einzigen dominanten Geschäftslinie ist das fast immer richtig. Der Koordinationsaufwand ist gering, weil es nicht viel zu koordinieren gibt.

Sie bricht auf zwei Achsen: Skalierung und Domänendistanz. Mit der Zahl der Geschäftsdomänen wird das zentrale Team zur Warteschlange. Ihm fehlt der Kontext zum Marketing-funnelfunnelThe customer journey from awareness to purchase, typically Awareness, Interest, Consideration, Decision, Action, with prospects narrowing at each stage.Vollständige Definition ansehen →, zur Supply Chain, zu den Aktuarsmodellen, sodass jede Anfrage teure Übersetzungsarbeit erfordert. Priorisierung wird politisch. Genau in diese Falle lief Meridian: Zentralisierung optimiert auf Kontrolle, direkt zulasten von Durchsatz und Nähe zum Business.

Föderiert: Argumente dafür und dagegen

Föderation bringt Datenkompetenz in die Business Units, dort, wo der Kontext liegt. Das Tempo steigt. Die Business-Relevanz steigt. Die Analysten des kommerziellen Teams verstehen das Geschäft tatsächlich.

Der Failure Mode ist Entropie. Ohne starkes Zentrum bekommen Sie Definitionsdrift (Meridians elf „aktive Kunden“), doppelte Ausgaben und, das ist das karrierebeendende Thema, inkonsistente Governance. Wenn jede Einheit ihre eigenen Zugriffs- und Aufbewahrungsregeln setzt, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen Sie die Frage einer Aufsichtsbehörde nicht beantworten, wo alle Kopien der Einwilligung einer betroffenen Person liegen. Reine Föderation ist nur dann tragfähig, wenn die Einheiten wirklich unabhängig sind (eine Holding, eigenständige regulierte Einheiten) oder wenn Sie über ungewöhnlich ausgereifte Engineering-Disziplin verfügen.

Hub-and-Spoke: Argumente dafür und dagegen

Bei Hub-and-Spoke landen die meisten CDOs, und das aus gutem Grund. Der hub besitzt die Plattform, die gemeinsamen Standards, das Policy-framework und die wiederverwendbaren zentralen Data Products. Die spokes, eingebettete Datenteams in jeder Domäne, besitzen Analytics, domänenspezifische Produkte und die Ausführung gemäß den Standards des hub.

Das entscheidende Designdetail: Spokes haben eine gepunktete Linie zum CDO und eine durchgezogene zum Business (oder umgekehrt, siehe unten). Governance ist im spoke nicht optional; sie wird vererbt. Der hub publiziert die Definition „aktiver Kunde“; spokes konsumieren sie und kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen sie ohne Governance-Prozess nicht forken.

Sein Failure Mode ist die unklare Mitte. Wenn die Grenze zwischen hub und spoke nicht explizit ist, bekommen Sie entweder einen hub, der sich wie ein Flaschenhals verhält (Rückfall in zentralisierte Dysfunktion), oder spokes, die still und leise eigene Wege gehen (Rückfall in föderierte Entropie). Hub-and-Spoke verlangt von den drei Modellen die meiste operative Disziplin.

Das Auswahl-framework: vier Kräfte

Wählen Sie kein Modell aus einer Speisekarte. Leiten Sie es aus vier Kräften ab, die für Ihr Unternehmen spezifisch sind.

1. Data Maturity (der Gating-Faktor). Ein föderiertes oder Hub-and-Spoke-Modell *erfordert* die Fähigkeit, Standards durchzusetzen, ohne die Arbeit physisch zu kontrollieren. Wenn Ihr Datenkatalog eine Absichtserklärung ist, Ihr Lineage manuell läuft und Ihre Governance auf Quartals-E-Mails basiert, verteilt das Verteilen der Arbeit nur Chaos. Geringe Maturity → erst zentralisieren, dann föderieren. Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen nicht delegieren, was Sie noch nicht standardisieren kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen. Deshalb scheiterte Meridians Föderation: Sie verteilten, bevor sie die Guardrails hatten, die Verteilung sicher machen.

2. Heterogenität des Geschäfts. Wie unterschiedlich sind die Domänen? Ein SaaS-Unternehmen mit einem einzigen Produkt hat geringe Heterogenität, Zentralisierung skaliert problemlos. Ein Konglomerat aus Versicherung, Retail und Fertigung hat extreme Heterogenität; Zentralisierung garantiert eine Übersetzungssteuer auf jede Entscheidung. Hohe Heterogenität drückt in Richtung spokes.

3. Regulatorische Konzentration. In stark regulierten, querschnittlichen Umfeldern (DSGVO über Regionen hinweg, Finanzberichterstattung, klinische Daten) sind die Kosten inkonsistenter Governance existenziell. Das zieht *Policy* zum hub, selbst wenn die Ausführung verteilt ist. Beachten Sie: Diese Kraft wirkt auf einzelne Aktivitäten, nicht auf das gesamte Modell, daher die Tabelle nach Aktivitäten oben.

4. Talentknappheit und Geografie. KKThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen Sie tatsächlich genug erfahrene Datenleute einstellen, um spokes zu besetzen? Wenn der Talentpool dünn ist, ist ein zentrales Center of Excellence mit rotierendem Einsatz möglicherweise die einzige realistische Option, unabhängig davon, was die Theorie bevorzugt.

Bewerten Sie jede Kraft. Ist die Maturity gering, dominiert diese Kraft: zentralisieren, bis Sie den Standardisierungsmuskel aufgebaut haben. Ist die Maturity ausreichend und die Heterogenität hoch, gewinnt Hub-and-Spoke. Reine Föderation ist selten und sollte ein „Beweisen Sie es“-Gespräch auslösen.

Ein durchgerechnetes Beispiel

Ein Spezialchemie-Unternehmen mit 4 Mrd. Dollar Umsatz: vier Divisionen, mittlere Data Maturity (ein echter Katalog, teilautomatisiertes Lineage), starke regulatorische Exponierung in einer Division (Vorprodukte für Spezialpharma) und ein knapper Talentmarkt in der Stadt des Hauptsitzes.

Wenden Sie die Kräfte an: Maturity ist ausreichend (Verteilung steht also zur Debatte), Heterogenität ist hoch (vier wirklich unterschiedliche Geschäfte), Regulierung ist auf eine Division konzentriert, Talent ist knapp. Die Antwort ist nicht ein Modell, sondern Hub-and-Spoke mit einem asymmetrischen spoke. Die drei kommerziellen Divisionen erhalten schlanke eingebettete spokes. Die Pharma-Division behält angesichts des regulatorischen Gewichts eine stärkere Governance-Präsenz, wobei der hub engere Policy-Kontrolle behält. Weil Talent knapp ist, betreibt der hub ein gemeinsames Plattformteam, auf das alle spokes zugreifen, statt dass jeder spoke eigene Infrastruktur baut. Das ist das Urteilsvermögen, das einen CDO von einem framework unterscheidet: Das Modell kann im Unternehmen ungleichmäßig angewendet werden.

Hub-and-Spoke tatsächlich zum Funktionieren bringen

Angenommen, Sie landen dort, wo die meisten großen Unternehmen landen, hier ist das operative How-to, das über Erfolg oder Scheitern entscheidet.

Definieren Sie das Spoke-Charter explizit. Jeder spoke sollte ein schriftliches Charter haben, das festhält, was ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → besitzt, was ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → vom hub erbt und welche SLAs ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → gegenüber dem Business hat. Unklarheit an dieser Stelle ist die häufigste Ursache für das Scheitern von Hub-and-Spoke.

Bringen Sie die Berichtslinien in Ordnung. Es gibt zwei tragfähige Strukturen:

• *Durchgezogene Linie zum CDO, gepunktet zum Business:* stärkere Durchsetzung von Standards, schwächere Business-Ausrichtung. Wählen Sie das, wenn Governance- und Regulierungskräfte dominieren.
• *Durchgezogene Linie zum Business, gepunktet zum CDO:* stärkere Business-Ausrichtung, erfordert stärkere *systemische* Kontrollen, um Drift zu verhindern. Wählen Sie das, wenn Tempo und Nähe zum Business dominieren und Ihre Plattform Standards automatisch durchsetzen kann.

Die zweite Variante funktioniert nur, wenn Standards durch tooling durchgesetzt werden, nicht durch organisatorische Autorität. Was zum wichtigsten Punkt führt:

Machen Sie Governance zu einer Eigenschaft der Plattform, nicht zu einem Komitee. Die Macht des hub in einem verteilten Modell kommt nicht daraus, Arbeit zu genehmigen, sondern daraus, den regelkonformen Weg zum einfachen Weg zu machen. Zertifizierte Data Products, Policy-as-Code und gemeinsame Definitionen müssen *technisch* durchgesetzt werden. Ein spoke, der auf der Plattform baut, sollte die richtigen Zugriffskontrollen und die kanonische Kundendefinition per default bekommen.

# Beispiel: ein Data-Product-Contract, den der Hub bei jedem Spoke durchsetzt
data_product: customer_360
owner: commercial_spoke_emea
inherits_definitions_from: hub_master_data   # kann ohne Governance-PR nicht geforkt werden
classification: pii_restricted               # Policy-as-Code, Hub-kontrolliert
access_policy: role_based
sla:
  freshness: 24h
  availability: 99.5%
governance:
  certified: true
  steward: emea_data_lead

Wenn Definition und Klassifizierung als vererbt deklariert und in der pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → durchgesetzt werden, *kann* ein spoke nicht stillschweigend seinen eigenen „aktiven Kunden“ erfinden oder PII-Kontrollen abschwächen. So bekommen Sie das Tempo der Föderation ohne die Entropie der Föderation.

Instrumentieren Sie die Grenze. Verfolgen Sie die Metriken, die zeigen, ob das Modell driftet: Anzahl geforkter/doppelter Definitionen (sollte gegen null gehen), Time-to-first-Dashboard (sollte niedrig bleiben, steigt sie, wird der hub zum Flaschenhals) und Anteil der Data Products, die auf zertifizierten Plattform-Assets gebaut sind, gegenüber Schattenbauten (Ihr Frühwarnsystem für Schatten-IT).

Das Modell über Zeit weiterentwickeln

Das Operating Model ist keine dauerhafte Wahl, es ist eine Funktion der Maturity und sollte sich bewusst weiterentwickeln. Die gesunde Entwicklung für die meisten wachsenden Unternehmen:

Zentralisieren → Hub-and-Spoke → selektive tiefe Föderation. Starten Sie zentralisiert, um den Muskel für Standards, Plattform und Governance aufzubauen. Sobald diese kodifiziert und im tooling durchsetzbar sind, schieben Sie die Ausführung zu den spokes hinaus. Nur die reifsten Organisationen, mit vollständig in der Plattform eingebetteter Governance, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen sicher tief föderieren, und selbst sie behalten einen hub für Policy und Kernprodukte.

Meridians Fehler war, das Maturity-Gate zu überspringen und von zentralisiert direkt zu föderiert zu springen, ohne die Durchsetzungsschicht zu bauen, die Verteilung sicher macht. Der Pendelschlag war ein Symptom dafür, das Modell als Ideologie und nicht als maturity-abhängiges Design zu behandeln.

Signale, dass es Zeit ist, sich *in Richtung* Verteilung zu entwickeln: Das zentrale Team ist ein dauerhafter Flaschenhals, Business Units bauen Schattenteams, und Ihre Standards sind jetzt im tooling durchsetzbar. Signale, dass Sie *zu weit* verteilt haben: Definitionsdrift, Governance-Lücken, die in Audits auftauchen, und doppelte Infrastrukturausgaben. Beobachten Sie das aktiv, das richtige Modell dieses Jahres ist in drei Jahren das falsche.

Wichtigste Erkenntnisse

1. Zerlegen, bevor Sie entscheiden. Wählen Sie kein Modell von einer Speisekarte, ordnen Sie Entscheidungsrechte Aktivität für Aktivität zu (Plattform, Definitionen, Governance, Analytics, Produkte). Die meisten realen Antworten sind asymmetrische Teilungen, keine reinen Archetypen.

2. Maturity ist die entscheidende Kraft. Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen nicht delegieren, was Sie nicht standardisieren kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen. Wenn Governance über E-Mails statt über tooling läuft, zentralisieren Sie zuerst und bauen Sie die Durchsetzungsschicht, bevor Sie verteilen.

3. Bei Hub-and-Spoke muss Governance eine Eigenschaft der Plattform sein. Machen Sie den regelkonformen Weg zum einfachen Weg, über Policy-as-Code und vererbte Definitionen. Die Macht des hub kommt aus tooling-defaults, nicht aus Komiteegenehmigungen.

4. Schreiben Sie das Spoke-Charter und legen Sie Berichtslinien bewusst fest. Unklarheit an der Grenze zwischen hub und spoke ist die häufigste Ursache für Scheitern. Durchgezogene Linie zum CDO bei regulatorischem Gewicht; durchgezogene Linie zum Business nur, wenn Ihr tooling Standards automatisch durchsetzt.

5. Instrumentieren Sie die Grenze und entwickeln Sie bewusst weiter. Verfolgen Sie doppelte Definitionen, Time-to-first-Dashboard und den Anteil der Schattenbauten. Das richtige Modell ist maturity-abhängig, rechnen Sie damit, von zentralisiert zu Hub-and-Spoke zu wechseln, sobald Ihr Standardisierungsmuskel stärker wird, und bewerten Sie jährlich neu.