.png){kind=small}
Power BI Center of Excellence: Rollen, Operating Model und Reifegrad
- Dirk Müller
- vor 17 Stunden
- 5 Min. Lesezeit
Aktualisiert: vor 3 Minuten
Ein Power BI Center of Excellence scheitert selten daran, dass niemand Best Practices kennt. Es scheitert häufiger daran, dass Verantwortung, Services und Entscheidungsrechte unklar bleiben. Ein gutes CoE ist deshalb weder BI-Polizei noch Helpdesk mit neuem Namen – und auch keine Organigramm-Box, die ohne Services und Entscheidungsrechte Wirkung erzeugt. Es ist das Operating Model, das Governance, Plattform, Standards und Enablement in wiederholbare Leistungen übersetzt.
Braucht ihr überhaupt ein Power BI Center of Excellence?
Nicht jedes Unternehmen braucht sofort ein großes formales Kompetenzzentrum. Microsoft beschreibt ein Data-/Analytics-CoE als internes Team aus technischen und fachlichen Experten, das andere Menschen im Unternehmen aktiv unterstützt. Entscheidend ist weniger die Organigramm-Box als die Frage, ob Rollen, Verantwortlichkeiten und Prioritäten tatsächlich geklärt sind.
Ein CoE wird sinnvoll, wenn Power BI oder Microsoft Fabric nicht mehr nur in einzelnen Teams genutzt wird, sondern Skalierungsprobleme entstehen: doppelte semantische Modelle, uneinheitliche Standards, wiederkehrende Supportfragen, unklare Ownership, zu viele Sonderlösungen oder Konflikte zwischen Self Service und Governance.
Wenn dagegen nur wenige zentrale Reports existieren und Plattform, Ownership und Support eindeutig organisiert sind, kann ein schlankes virtuelles CoE genügen. Die bessere Frage lautet: Welche wiederkehrenden Aufgaben brauchen klare Verantwortung und einen verlässlichen Service?
Was ein CoE leisten sollte – und was nicht
Microsoft nennt unter anderem Mentoring, Training, Office Hours, Governance-Unterstützung, Plattform- und Architekturthemen, Best-Practice-Reviews, Proofs of Concept sowie koordinierte Kommunikation.
Daraus leiten wir vier Servicefelder ab: Guardrails & Governance, Platform & Quality, Enablement & Community sowie Improvement & Measurement. Diese vier Bereiche sind keine Microsoft-Produktvorgabe, sondern unsere Daten-WG-Synthese auf Basis der Adoption- und Governance-Guidance.
Was ein CoE nicht sein sollte: ein Genehmigungsgremium für jede Kleinigkeit, eine zentrale Entwicklungsabteilung, die sämtliche Fachbereiche ersetzt, oder ein Supportpostfach ohne Einfluss auf Standards und Plattformentscheidungen. Ein CoE, das nur Regeln formuliert, aber keinen einfachen Happy Path anbietet, fördert Umgehungsverhalten statt Governance.
Zentral oder föderiert? Wichtigste Strukturentscheidung
Microsoft unterscheidet zentralisierte, unified, föderierte und dezentralisierte Modelle. Ein zentrales CoE bündelt Know-how und Verantwortung in einem gemeinsamen Team. Das erleichtert den Start und eignet sich, wenn Plattform und Datenorganisation stark zentral gesteuert werden. Das Risiko: Das Team wird zum Flaschenhals oder entwickelt fachferne Standards.
Ein föderiertes CoE kombiniert ein Kernteam mit Vertretern in Geschäftsbereichen. Das bringt Domänenwissen näher an Governance und Enablement und verteilt Verantwortung. Dafür braucht es klare Spielregeln: Wer entscheidet was? Wie viel Kapazität haben die Vertreter? Welche Standards sind verbindlich, welche lokal anpassbar?
Unsere Faustregel: Je stärker Datenverantwortung und Analytics-Entwicklung in Fachdomänen verteilt sind, desto eher sollte das CoE föderiert arbeiten. Je stärker Plattform, Datenmodelle und Reporting zentral bereitgestellt werden, desto eher kann ein zentrales Modell funktionieren.
Entscheidungsmatrix für das Operating Model
Kriterium | Eher zentral | Eher föderiert |
Zahl der Fachdomänen | wenige | viele |
Analytics Ownership | zentral | verteilt |
Regulatorik/Standardisierung | sehr hoch | hoch, aber domänenspezifisch |
Self-Service-Anteil | niedrig bis mittel | hoch |
Domänenwissen im Kernteam | hoch | verteilt |
Bedarf an lokalen Champions | gering | hoch |
Plattformarchitektur | stark standardisiert | gemeinsame Plattform, unterschiedliche Nutzung |
Risiko eines Bottlenecks | überschaubar | hoch bei Zentralisierung |
Viele Unternehmen landen sinnvollerweise bei einem unified oder föderierten Modell: Ein kleines starkes Kernteam definiert Plattform, Guardrails und gemeinsame Services; Fachbereiche übernehmen dort Verantwortung, wo Domänenwissen und Adoption entscheidend sind.
Welche Rollen braucht ein Power BI CoE?
Rollen müssen nicht zwingend Vollzeitstellen sein. Sie müssen aber eindeutig besetzt sein. Ein pragmatischer Start umfasst CoE Lead, Fabric/Power BI Admin, Governance-/Data-Verantwortliche, Semantic Model Owner, Domain Owner, Champions und Trainer/Coach. Wichtig ist die Trennung von „wer berät“, „wer betreibt“, „wer entscheidet“ und „wer fachlich besitzt“. Genau dort entstehen sonst Schattenprozesse.
Das RACI ist eine Startlogik, keine universelle Vorgabe. In regulierten oder sehr großen Organisationen müssen Risk, Security, Data Stewardship und interne Revision expliziter ergänzt werden.
Reifegrad – vom Supportmodus zum messbaren Operating Model
Microsoft arbeitet in seiner Adoption Roadmap mit Reifegraden von 100 bis 500. Das folgende 4-Stufen-Modell ist ausdrücklich keine Microsoft-Systematik, sondern unsere Daten-WG-Verdichtung für die praktische CoE-Arbeit.
1. Reaktiv: Wissen sitzt bei Einzelpersonen. Support entsteht ad hoc. Standards sind Empfehlungen, Ownership ist unklar.
2. Gemanagt: Charter und Service-Portfolio existieren. Es gibt definierte Rollen, Office Hours, erste Trainings und grundlegende Standards.
3. Föderiert: Fachdomänen und Champions sind strukturell eingebunden. Zertifizierung, gemeinsame semantische Modelle und wiederholbare Governance-Prozesse funktionieren über Teamgrenzen hinweg.
4. Gemessen: Ziele und KPIs werden regelmäßig überprüft. Services werden nach Wirkung priorisiert. Technische Schulden, Adoption, Qualität und Plattformkosten fließen in kontinuierliche Verbesserung ein.
Ein Unternehmen muss nicht sofort Stufe 4 anstreben. Der sinnvollste nächste Schritt ist derjenige, der die größte aktuelle Reibung beseitigt.
Welche KPIs zeigen, ob das CoE funktioniert?
Ein CoE sollte nicht an der Zahl veröffentlichter Guidelines gemessen werden. Besser sind Kennzahlen, die Wirkung zeigen: Anteil wiederverwendeter bzw. zertifizierter semantischer Modelle, Trend wiederkehrender Supportprobleme, Time-to-Value, Reichweite des Champions-Netzwerks, Standardkonformität, Zahl redundanter Modelle/Reports, Nutzung und Zufriedenheit der CoE-Services sowie Plattformkosten und vermeidbare Nacharbeit.
KPIs sollten zum Auftrag passen. Ein CoE mit Fokus auf Enablement braucht andere Erfolgsmaße als ein Team, das vor allem Governance und Plattformqualität stabilisieren soll.
Die häufigsten Anti-Patterns
BI-Polizei: Das CoE kontrolliert, bietet aber keinen einfachen Happy Path. Nutzer umgehen die Regeln.
Helpdesk-only: Das Team beantwortet Tickets, beseitigt aber keine strukturellen Ursachen.
Standards ohne Ownership: Es gibt Dokumente, aber niemand entscheidet bei Konflikten oder aktualisiert sie.
Zentrale Engstelle: Alle wichtigen Aufgaben landen beim Kernteam; Self Service wird faktisch abgeschafft.
Föderation ohne Kapazität: Satellitenrollen existieren auf dem Papier, haben aber keine Zeit oder klaren Ziele.
Vanity Metrics: Trainingsanzahl oder Seitenaufrufe werden gefeiert, obwohl Qualität und Wiederverwendung nicht steigen.
Ein pragmatischer Start in 90 Tagen
In den ersten 30 Tagen nehmt ihr die größten Reibungspunkte auf, sichert einen Sponsor, schreibt eine kurze Charter und definiert fünf bis acht konkrete Services. In den Tagen 31 bis 60 werden Rollen, Entscheidungsrechte und ein erster Governance-/Enablement-Rhythmus festgelegt. Startet bewusst klein, etwa mit Office Hours, Modellreview, Standards und Champions-Austausch.
In den Tagen 61 bis 90 messt ihr Nutzung und Wirkung. Erst danach entscheidet ihr, welche Services ausgebaut, automatisiert oder in Fachbereiche föderiert werden.
Fazit
Ein Power BI Center of Excellence ist kein Selbstzweck. Sein Wert entsteht, wenn es Reibung reduziert: weniger doppelte Lösungen, klarere Verantwortlichkeiten, bessere Wiederverwendung und schnelleres Enablement innerhalb sinnvoller Guardrails. Für viele Organisationen ist ein kleines Kernteam mit klaren Services und föderierter Fachbereichseinbindung belastbarer als ein großes zentrales Kompetenzzentrum. Entscheidend ist nicht die Zahl der Rollen, sondern ob Governance, Plattform und Befähigung als zusammenhängendes Operating Model funktionieren.
Der nächste sinnvolle Schritt
Wenn Power BI bei euch bereits breit genutzt wird, aber Ownership, Governance und Enablement nicht mehr sauber skalieren, ist ein CoE-Design oft sinnvoller als noch eine weitere Einzelrichtlinie.
Im Kontext Power BI Governance können wir Rollen, Guardrails und Operating Model gemeinsam strukturieren. Ergänzend helfen Power BI Coaching, Power BI Training und unser Beitrag zu Power BI Governance im Self Service.
