Hub-and-Spoke-Datenteams: das Modell, das richtig klingt und schlecht funktioniert

Das Hub-and-Spoke-Modell hat es als anerkannte Weisheit erstaunlich weit gebracht. Bitten Sie einen beliebigen Unternehmensberater, eine Organisationsstruktur für eine Datenfunktion in einem Unternehmen mit mehr als drei Geschäftsbereichen zu skizzieren, und Sie bekommen mit ziemlicher Sicherheit einen Kreis in der Mitte zu sehen, Linien, die nach außen führen, und ein paar Formulierungen über „embedded Analysts“, die an die Zentrale berichten, aber im Geschäftsbereich sitzen. Es wirkt wie ein Kompromiss, mit dem alle zufrieden sind. Genau deshalb scheitert es meistens.

Die gängige Sichtweise, fair dargestellt

Das Argument für Hub-and-Spoke ist durchaus schlüssig. Vollständig zentralisierte Datenteams leiden unter einer gut dokumentierten Pathologie: Sie werden zum Engpass. Geschäftsbereiche stehen für Analysen Schlange, Prioritäten setzt, wer am lautesten ruft oder das meiste politische Kapital hat, und lokales Domänenwissen verkümmert, weil die Analysten, die heute an Retail-Problemen arbeiten, im nächsten Quartal in die Supply Chain versetzt werden. Gartner hat wiederholt belegt, dass zentralisierte Datenorganisationen bei der Zufriedenheit der Fachbereiche schlecht abschneiden, teils wegen langer Durchlaufzeiten, teils weil die Ergebnisse operative Feinheiten oft verfehlen.

Vollständig dezentrale Modelle lösen das Nähe-Problem, schaffen aber ein anderes. Standards fragmentieren. Derselbe Kunde wird in drei Geschäftsbereichen unterschiedlich definiert. Eine Data-Mesh-Architektur, wie sie Zhamak Dehghani in ihrer Arbeit bei Thoughtworks formuliert hat, wollte das über föderierte Ownership mit zentralen Plattformstandards adressieren, doch viele Organisationen stellten fest, dass ihnen die Data-Engineering-Reife fehlte, um Self-Service-Infrastruktur real werden zu lassen.

Hub-and-Spoke sieht nach der Synthese aus. Ein zentrales Team verantwortet Governance, Standards und gemeinsame Infrastruktur. Eingebettete „Spoke“-Analysten sitzen in den Geschäftsbereichen und bauen Domänenexpertise auf. Alle gewinnen. Der CDO behält die Autorität, das Business bekommt Reaktionsschnelligkeit.

Wo das Modell in der Praxis bricht

Das Problem liegt nicht am Diagramm. Es liegt an dem, was das Diagramm nicht zeigen kann: wer tatsächlich über Zeit, Karriere und Prioritäten des Spoke-Analysten bestimmt.

In den meisten Umsetzungen hat der Spoke-Analyst zwei Berichtslinien, eine durchgezogene zum Leiter des Geschäftsbereichs oder zu einem lokalen Analytics-Manager, eine gestrichelte zum zentralen CDO oder Head of Data. In der Praxis ist die gestrichelte Linie Dekoration. Der Geschäftsbereich kontrolliert Gehaltsrunden, Projektzuweisungen und die tägliche Arbeit. Innerhalb von sechs Monaten ist der Spoke-Analyst vom Business absorbiert worden, und die Zentrale hat jeden nennenswerten Einfluss darauf verloren, was diese Person tut.

Die Folge: Governance-Zusagen, die an der Spitze der Organisation gemacht werden, erreichen nicht den Ort, an dem Daten tatsächlich entstehen und genutzt werden. Ein Finanzdienstleister mit diesem Modell mag sein zentrales Team eine Data-Quality-Policy veröffentlichen lassen, während die im Trading Desk eingebetteten Spoke-Analysten Pipelines bauen, die den freigegebenen Datenkatalog komplett umgehen, weil die Zeitpläne des Trading Desk den Freigabeprozess nicht hergeben. Die Zentrale erfährt davon, wenn etwas kaputtgeht, nicht vorher.

Es gibt außerdem ein Talentproblem, das selten beim Namen genannt wird. Spoke-Analysten in diesem Modell haben tendenziell schlechtere Karriereverläufe als ihre Kollegen, die vollständig im zentralen Team sitzen. Das zentrale Team bekommt Berührung mit Enterprise-Architektur, KI-Infrastruktur und bereichsübergreifender Mustererkennung. Der Spoke-Analyst wird sehr gut in den Problemen eines Geschäftsbereichs und zunehmend schwer zu befördern oder umzusetzen. Unternehmen wie große europäische Banken und Konsumgüterkonzerne berichten genau aus diesem Grund von Schwierigkeiten, Spoke-Analysten nach zwei oder drei Jahren zu halten. Die Rolle ist weder interessant genug, um technisch ambitionierte Leute zu binden, noch senior genug, um kommerziell ambitionierte zufriedenzustellen.

Auch der Koordinationsaufwand ist höher, als 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 → aussieht. Hub-and-Spoke setzt voraus, dass der Hub die Kapazität hat, die Spokes tatsächlich zu bedienen: Standards setzen, Arbeit reviewen, gemeinsame Infrastruktur pflegen, Schulungen durchführen und Konflikte zwischen Datendefinitionen der Geschäftsbereiche auflösen. In der Größenordnung von Unilever oder bei einer Bank wie BNP Paribas, die Datenbetrieb in gut zwanzig Ländern führt, wird der Hub zum zweiten Engpass, weil er gemessen an der Koordinationsfläche, die er managen soll, unterbesetzt ist. Forschung der MIT Sloan Management Review zu Daten-Betriebsmodellen weist Governance-Kapazität als durchgängige Restriktion aus; Organisationen unterschätzen regelmäßig den Personalbedarf für ein glaubwürdiges Center of Excellence.

Effekte zweiter Ordnung verstärken das. Weil das Modell als Lösung des Spannungsfelds zwischen Zentralisierung und Dezentralisierung präsentiert wird, hören Organisationen oft auf zu iterieren, sobald das Organigramm gezeichnet ist. Das Modell wird zum politischen Kompromiss statt zum Betriebsdesign. Jede Interessengruppe kann auf die Struktur zeigen und behaupten, ihre Interessen seien vertreten. CDOs 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 sagen, sie seien „im Business eingebettet“. Geschäftsbereichsleiter können sagen, sie hätten „ihre eigenen“ Datenleute. Keine der beiden Aussagen stimmt so richtig, und die Mehrdeutigkeit bleibt auf unbestimmte Zeit bestehen, weil sie offenzulegen bedeuten würde, dass jemand etwas verliert.

Was ein guter CDO tatsächlich tun sollte

Erkennen Sie an, dass Hub-and-Spoke eine Übergangsarchitektur ist, kein Ziel. Es kann ein vernünftiger Zwischenschritt sein, wenn man von einem chaotischen, vollständig dezentralen Zustand zu etwas Disziplinierterem will. Der Fehler besteht darin, es als Endzustand zu behandeln.

Wenn Sie es betreiben, muss das Arbeitsverhältnis ehrlich sein. Entweder berichtet der Spoke-Analyst an die Zentrale und ist an den Geschäftsbereich entsandt, wobei die Zentrale Karriereentwicklung, Vergütung und Rückrufrechte steuert, oder der Spoke-Analyst ist Mitarbeiter des Geschäftsbereichs, und die Rolle der Zentrale besteht darin, technische Standards zu setzen und gemeinsames Tooling bereitzustellen, nicht darin, Autorität über Menschen vorzutäuschen, die sie nicht führt. Die Fiktion der doppelten Berichtslinie kostet alle Beteiligten Zeit und erzeugt Ressentiments in beide Richtungen.

Der Hub braucht außerdem ein Service Level Agreement, das aus Sicht des Geschäftsbereichs geschrieben ist, nicht aus Sicht der Zentrale. Wenn der zentrale Governance-Prozess drei Wochen braucht, um eine neue Datenquelle freizugeben, wird der Spoke-Analyst ihn umgehen. Die SLA-Disziplin zwingt die Zentrale, über ihre eigenen Kapazitätsgrenzen ehrlich zu sein.

Prüfen Sie den Data-Mesh-Weg ernsthaft, aber nur, wenn Sie die Plattform-Engineering-Reife dafür haben. Unternehmen wie Zalando, bei denen föderierte Data Ownership funktioniert, haben das auf jahrelangen Investitionen in internes Developer-Tooling aufgebaut und auf einer Kultur, in der Domänenteams ihre Produktionssysteme wirklich end-to-end verantworten. Ohne dieses Fundament ist 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 → Hub-and-Spoke mit besserem Marketingtext.

Die beständigsten Datenorganisationen haben in der Regel eines gemeinsam: Klarheit darüber, wo Entscheidungen tatsächlich getroffen werden, nicht darüber, wo das Organigramm es nahelegt. Zeichnen Sie die reale Entscheidungslandkarte, bevor Sie sich auf eine Struktur festlegen, und Sie machen weniger Zusagen, die das Modell nicht halten kann.