Shared Services vs. cross-funktionale Teams – eine Flow-Perspektive

In der agilen Welt wird häufig diskutiert, ob Shared Services oder cross-funktionale Teams die bessere Wahl sind. Aus der Perspektive von Flow-Metriken und der Optimierung von Wertströmen gibt es klare Szenarien, in denen Shared Services Vorteile bieten und ebenso Situationen, in denen integrierte Teams überlegen sind. Wann ist zentralisierte Expertise sinnvoll und wann sorgen integrierte Teams für den besseren Fluss?

Die Beantwortung dieser Frage ist nicht nur eine methodische, sondern auch eine strategische Entscheidung. Sie wirkt sich darauf aus, wie schnell Organisationen auf Veränderungen reagieren können, wie transparent ihre Prozesse sind und wie effizient Ressourcen genutzt werden. Beide Modelle haben ihre Berechtigung, doch ihr Erfolg hängt stark vom jeweiligen Kontext ab – etwa von der Art der Arbeit, der Häufigkeit spezieller Anforderungen oder der Reife der Organisation in Bezug auf Zusammenarbeit und Selbstorganisation.

Grundlage dieser Betrachtung sind Erkenntnisse aus der Flow-Analyse sowie aus dem evolutionären Change-Management-Ansatz im Kanban-Umfeld. Dabei kommen Messgrößen wie Work in Progress (WIP), Cycle Time und Throughput zum Einsatz, um faktenbasiert zu erkennen, welche Struktur im konkreten Fall den größten Mehrwert bringt. Ziel ist es, den Wertstrom so zu gestalten, dass Wartezeiten minimiert, Risiken kontrolliert und Kapazitäten optimal genutzt werden.

Shared Services: Fälle für zentralisierte Expertise

Hohe Spezialisierung und Risikomanagement

Shared Services sind ideal, wenn es um hochspezialisierte Skills wie Compliance, Sicherheitsaudits oder komplexe Datenanalyse geht. Die Kosten, diese Expertise in jedem Team zu duplizieren, sind oft prohibitiv, nicht nur finanziell, sondern auch organisatorisch, da das notwendige Know-how kontinuierlich geschult und aktuell gehalten werden muss.

Laut den Prinzipien des Kanban Maturity Models ermöglichen Shared Services eine Risikostreuung, indem sie kritische Aufgaben bündeln und standardisieren. So lassen sich fachliche Standards leichter durchsetzen und Abweichungen oder Sicherheitslücken schneller erkennen.

Beispiel: Ein zentrales Security-Team kann Bedrohungen effizienter analysieren und Incident-Response-Prozesse optimieren, während cross-funktionale Teams sich auf Feature-Entwicklung konzentrieren. In einer Bank könnte dies bedeuten, dass ein spezielles Team alle Penetrationstests durchführt, um regulatorische Vorgaben einzuhalten, statt dass jedes Produktteam eigene Sicherheitsprüfungen improvisiert.

Batch-Verarbeitung und geplante Verfügbarkeit

Wenn Aufgaben wie etwas Datenbank-Migrationen, komplexe Infrastrukturänderungen oder rechtliche Prüfungen Ressourcen erfordern, die nicht jederzeit verfügbar sind, ist ein Shared Service sinnvoll. Kanban empfiehlt in solchen Fällen Pufferung und Pull-Prinzipien, um Wartezeiten zu minimieren.

Das bedeutet, dass Anfragen gesammelt, priorisiert und in geplanten Intervallen bearbeitet werden. So wird verhindert, dass spontane Anfragen den Arbeitsfluss stören.

Beispiel: Ein Shared Legal-Team bearbeitet Vertragsprüfungen in Batches, statt einzelne Teams mit ad-hoc-Anfragen zu überlasten. In der Praxis könnte dies bedeuten, dass alle Vertragsprüfungen einmal pro Woche gebündelt werden, um Synergien zu nutzen und Bearbeitungszeiten vorhersehbarer zu machen.

Skaleneffekte und Auslastungsoptimierung

Bei schwankender Nachfrage oder komplementären Workloads steigern Shared Services die Kapazitätsauslastung. Littles Law (Cycle Time = WIP / Throughput) zeigt, dass zentralisierte Ressourcen den Gesamtdurchsatz erhöhen können, selbst wenn die Transaktionskosten für Koordination leicht steigen.

Zentralisierung ermöglicht es, Kapazität dort einzusetzen, wo sie gerade am meisten gebraucht wird. Dadurch lassen sich Engpässe in einzelnen Teams reduzieren und gleichzeitig Leerlauf vermeiden.

Beispiel: Ein DevOps-Team, das Infrastruktur für mehrere Produktteams bereitstellt, kann Tools, Automatisierungen und Best Practices zentral entwickeln, wodurch sich die Implementierungsgeschwindigkeit aller Teams erhöht. In Spitzenzeiten, etwa bei einer großen Release-Welle, kann es Prioritäten anpassen und Kapazitäten dorthin verschieben, wo der größte Effekt auf den Wertstrom entsteht.

Cross-funktionale Teams: Wenn Integration priorisiert wird

Sofortige Verfügbarkeit und reduzierte Koordinationskosten

Cross-funktionale Teams glänzen, wenn schnelle Feedback-Zyklen und minimale Wartezeiten entscheidend sind. Laut Dan Vacanti verkürzen integrierte Skills die Cycle Time, da Abhängigkeiten entfallen. Ein Scrum-Team mit eigenem UX-Designer und Tester liefert Features schneller, als wenn es auf externe Services warten müsste.

Die sofortige Verfügbarkeit von Kompetenzen direkt im Team reduziert nicht nur Wartezeiten, sondern auch den Kommunikationsaufwand. Entscheidungen können unmittelbar getroffen, Tests zeitnah durchgeführt und Anpassungen sofort umgesetzt werden. Dadurch sinkt das Risiko, dass Anforderungen auf dem Weg zwischen verschiedenen Abteilungen verwässert oder missverstanden werden.

Beispiel: Ein E-Commerce-Team mit eigener Frontend-Entwicklung, Backend-Entwicklung, UX-Design und Testing kann innerhalb weniger Tage eine neue Checkout-Funktion entwerfen, entwickeln, testen und ausrollen. Würden Teile dieser Arbeit an Shared Services ausgelagert, könnten Wartezeiten auf Rückmeldungen oder Kapazitäten den gesamten Prozess um Wochen verzögern.

Kulturelle Faktoren und Vertrauen

In Organisationseinheiten mit hohem Vertrauen ermöglichen cross-funktionale Teams autonome Entscheidungen, ohne auf externe Freigaben warten zu müssen. Die Kanban-Prinzipien betonen, dass Teams mit eigener Prozesshoheit schneller und gezielter auf Kundenbedürfnisse reagieren können.

Autonomie fördert zudem die Motivation: Wer Entscheidungen eigenständig treffen darf, identifiziert sich stärker mit den Ergebnissen. Gleichzeitig entsteht im Team ein breiteres Verständnis für den gesamten Produktlebenszyklus, da alle Beteiligten die Auswirkungen ihrer Arbeit auf den Endnutzer sehen.

Beispiel: In einem Software-as-a-Service-Unternehmen kann ein cross-funktionales Produktteam neue Features direkt mit ausgewählten Kunden testen, Feedback einarbeiten und erneut ausrollen ohne auf formale Übergaben an andere Abteilungen angewiesen zu sein.

In konservativen Organisationen mit strengen Compliance-Vorgaben bleiben Shared Services jedoch oft notwendig, etwa um rechtliche Risiken zu minimieren oder verbindliche Standards sicherzustellen. In solchen Fällen können hybride Modelle sinnvoll sein, bei denen das Team autonom arbeitet, aber für bestimmte Prüfschritte auf zentrale Expertise zurückgreift.

Flow-Metriken als Entscheidungsgrundlage

Work in Progress (WIP) und Cycle Time

Ein überlasteter Shared Service wird im Cumulative Flow Diagram (CFD) durch wachsende WIP-Bänder sichtbar. Je breiter der Abstand zwischen der Linie „Anfang“ und der Linie „Ende“ wird, desto länger ist die durchschnittliche Durchlaufzeit. Das bedeutet: Aufgaben warten länger, bevor sie abgeschlossen werden, und das ist ein klares Zeichen für einen Engpass.

Warum das wichtig ist:

Wachsende WIP-Bänder weisen darauf hin, dass zu viele Aufgaben gleichzeitig bearbeitet werden.

Ein hoher WIP-Wert führt fast immer zu längeren Cycle Times, weil Aufgaben um Aufmerksamkeit konkurrieren und ständig Kontextwechsel stattfinden.

Gerade bei Shared Services können solche Engpässe schnell den gesamten Wertstrom verzögern, wenn viele Teams von derselben zentralen Einheit abhängig sind.

Beispiel: Ein zentrales UX-Team bearbeitet Anforderungen aus fünf verschiedenen Produktbereichen. Wenn jeder Bereich mehrere neue Designs einreicht, wächst das WIP stark an. Ohne Begrenzung müssen Teams mehrere Wochen warten, bis ihre Designs finalisiert sind, selbst wenn die eigentliche Designarbeit nur wenige Tage dauert.

Praktischer Ansatz: Durch WIP-Limits auf Service-Ebene lässt sich steuern, wie viele Aufgaben gleichzeitig im System sind. Das zwingt zu Priorisierung und verhindert, dass zu viele halbfertige Arbeiten den Fluss blockieren.

Durchsatz und Variabilität

Shared Services sollten ihren Durchsatz (Throughput) transparent machen, also wie viele Aufgaben in einem bestimmten Zeitraum tatsächlich abgeschlossen werden. Hier helfen Cycle-Time-Scatterplots, um sowohl den Durchschnitt als auch die Streuung der Durchlaufzeiten zu erkennen.

Warum das wichtig ist:

Eine geringe Streuung (z. B. unter 20 %) bedeutet, dass Aufgaben mit hoher Vorhersagbarkeit abgeschlossen werden. Das ist ideal für planbare, wiederkehrende Tätigkeiten wie Compliance-Prüfungen oder Standard-Deployments.

Eine hohe Streuung zeigt, dass manche Aufgaben deutlich länger dauern als andere. Das kann ein Hinweis auf fehlende Standardisierung, unklare Anforderungen oder häufige Unterbrechungen sein.

Beispiel: Ein Shared-Service-Team für Datenbankadministration schließt im Schnitt zehn Migrationen pro Monat ab. Liegt die Streuung bei ± 2 Tagen, können Produktteams verlässlich planen. Liegt sie bei ± 10 Tagen, ist die Planung deutlich schwieriger; ein Hinweis darauf, dass Prozesse optimiert oder Aufgaben anders strukturiert werden sollten.

Vergleich zu cross-funktionalen Teams: In innovativen Projekten mit hoher Unsicherheit, etwa wenn Anforderungen oft spontan entstehen, können cross-funktionale Teams flexibler reagieren, weil sie benötigte Kompetenzen direkt im Team haben und sich nicht an die Durchsatzrate eines Shared Service anpassen müssen.

Praktische Empfehlungen

Assessments durchführen

Messen Sie die Transaktionskosten für Shared-Service-Anfragen. Dazu zählen nicht nur direkte Bearbeitungszeiten, sondern auch Wartezeiten, Abstimmungsrunden und die Zeit, die Teams auf Feedback warten müssen. Analysieren Sie zudem, wie stark Spezialisten ausgelastet sind und wie oft im Wertstrom Sofortverfügbarkeit benötigt wird.

Praxis-Tipp:

• Führen Sie eine Wertstromanalyse durch, um Abhängigkeiten und Engpässe sichtbar zu machen.
• Nutzen Sie Metriken wie Cycle Time, WIP und Throughput, um die Ist-Situation zu quantifizieren.
• Dokumentieren Sie typische Prozessvarianten, um zu sehen, welche Aufgaben standardisierbar sind und welche nicht.

Hybride Modelle testen

Nutzen Sie Shared Services für klar abgegrenzte, selten benötigte oder hochspezialisierte Aufgaben (z. B. Compliance, Infrastruktur), aber integrieren Sie häufig benötigte Skills wie Testing, UX oder DevOps-Expertise direkt in die Teams. So profitieren Sie sowohl von Spezialisierung als auch von schneller Reaktionsfähigkeit.

Praxis-Tipp:

• Starten Sie mit einem Pilotprojekt, in dem ein bisher zentraler Skill testweise ins Team integriert wird.
• Beobachten Sie die Auswirkungen auf Durchlaufzeiten und Qualität.
• Halten Sie Servicevereinbarungen mit den zentralen Einheiten aufrecht, um bei Bedarf kurzfristig auf zusätzliche Kapazität zurückgreifen zu können.

WIP-Limits anpassen

Begrenzen Sie die Anzahl paralleler Anfragen an Shared Services, um Überlastung zu vermeiden. Dies lässt sich mit Kanban-WIP-Limits pro Servicekanal umsetzen. So verhindern Sie, dass dringende Aufgaben in einer Warteschlange hinter vielen weniger wichtigen Anfragen stecken bleiben.

Praxis-Tipp:

• Setzen Sie separate Limits für Standardaufgaben und für dringende Expedite-Fälle.
• Kommunizieren Sie diese Limits offen, damit alle Stakeholder die Konsequenzen verstehen.
• Nutzen Sie Visualisierung (Kanban-Boards, CFD), um Engpässe transparent zu machen.

Feedbackschleifen etablieren

Halten Sie regelmäßige gemeinsame Retrospektiven mit Shared-Service- und Produktteams ab, um Engpässe früh zu erkennen und Prozesse iterativ zu verbessern. So lassen sich Reibungsverluste reduzieren und Vertrauen zwischen den beteiligten Einheiten stärken.

Praxis-Tipp:

• Führen Sie monatliche oder quartalsweise Service-Reviews durch, in denen Metriken ausgewertet und Verbesserungsmaßnahmen beschlossen werden.
• Arbeiten Sie mit klaren Verbesserungshypothesen („Wenn wir X ändern, erwarten wir Y als Effekt“), um Maßnahmen gezielt zu testen.
• Dokumentieren Sie Erkenntnisse und teilen Sie sie organisationsweit, um Doppelarbeit zu vermeiden.

Abbildung: Tipps im Umgang mit Shared Services und cross-funktionalen Teams

Fazit

Die Entscheidung zwischen Shared Services und cross-funktionalen Teams hängt von mehreren Faktoren ab: dem Grad der Spezialisierung, der Nachfragestruktur, den Risiken bei der Aufgabenerfüllung und der organisatorischen Reife. Flow-Metriken wie Work in Progress (WIP), Cycle Time und Throughput bieten eine datengetriebene Grundlage, um diese Entscheidung nicht aus dem Bauch heraus, sondern evidenzbasiert zu treffen.

Shared Services punkten vor allem dort, wo spezialisierte Expertise selten, aber kritisch ist oder wo zentrale Standards zwingend einzuhalten sind. Sie können Risiken senken, Kapazitäten bündeln und Kosten optimieren, vorausgesetzt ihre Arbeit ist klar priorisiert, transparent und durch WIP-Limits vor Überlastung geschützt.

Cross-funktionale Teams entfalten ihre Stärke in Umgebungen, in denen schnelle Iterationen, direkte Kommunikation und sofortige Verfügbarkeit entscheidend sind. Sie verkürzen Entscheidungswege, erhöhen die Autonomie und verbessern die Reaktionsgeschwindigkeit auf Kundenfeedback.

In vielen Organisationen liegt die optimale Lösung nicht in einem Entweder-oder, sondern in einer hybriden Struktur. Häufig benötigte Kompetenzen werden ins Team integriert, während seltene oder hochspezialisierte Fähigkeiten zentral gebündelt bleiben. So entsteht eine Balance zwischen Effizienz und Reaktionsfähigkeit.

Letztlich gilt: Flexibilität entsteht nicht durch starre Strukturen, sondern durch klare Priorisierung, kontinuierliche Anpassung und den bewussten Einsatz von Flow-Daten. Wer Metriken konsequent misst, visualisiert und als Grundlage für Verbesserungen nutzt, kann beides erreichen: stabilen Fluss im Wertstrom und die Fähigkeit, schnell auf Veränderungen zu reagieren.

Hinweise: 

Wollen Sie Ihr Unternehmen so entwickeln, dass es Nutzer, Kunden und Entwickler wirklich inspiriert? Dann vernetzen Sie sich einfach mit Benjamin Igna auf LinkedIn und finden Sie ein Vorgehen, das genau zu Ihnen und Ihrem Kontext passt. Alternativ können Sie auch auf Stellar Work zugehen.

Wollen Sie als Meinungsmacherin oder Impulsgeber das Thema diskutieren? Dann teilen Sie den Beitrag gerne in Ihrem Netzwerk oder auf Social Media.

Benjamin Igna hat drei weitere Beiträge im t2informatik Blog veröffentlicht: