Cross-Team-Abhängigkeiten sichtbar machen: Wenn Engpässe wandern
Drei Teams zeigen gleichzeitig steigende Durchlaufzeiten. Die naheliegende Diagnose: Alle drei haben ein Problem. Die tatsächliche Ursache: Ein Team staut, und die anderen erben den Rückstand über die Kette. Wer alle drei Teams gleichzeitig optimiert, investiert dreifach – obwohl der Hebel bei einem einzigen Team liegt.
Einzelne Teams optimieren reicht nicht
IT-Organisationen analysieren ihre Performance pro Team. Jedes Team hat ein Dashboard, eine Queue, einen Teamleiter und eigene KPIs. Diese Silo-Perspektive funktioniert, solange die Teams unabhängig voneinander arbeiten.
In der Realität hängen Teams voneinander ab. Ein Identity-Management-Team kann keine Berechtigungstickets abschließen, solange das SAP-Basis-Team die technische Voraussetzung nicht geschaffen hat. Das Change Management wartet auf Freigaben, die durch mehrere Teams laufen. Der Service Desk nimmt Tickets an, die über eine Kette von drei Teams bearbeitet werden, bevor sie gelöst sind.
Wenn ein Glied dieser Kette staut, wartet alles dahinter. Nicht weil die nachgelagerten Teams schlechter arbeiten, sondern weil sie auf Zulieferung warten. Das Ergebnis: Mehrere Teams zeigen gleichzeitig steigende Durchlaufzeiten. Im Eskalationsmeeting erklärt jeder Teamleiter, dass sein Team "normal arbeitet, aber von den anderen zu spät beliefert wird". Alle haben recht. Und niemand löst das Problem.
Warum Team-Dashboards Abhängigkeiten verstecken
Ein Team-Dashboard zeigt den Zustand innerhalb eines Teams: Backlog-Größe, Durchlaufzeit, SLA-Erfüllung. Was es nicht zeigt: Woher kommt die Verzögerung? Liegt sie an der eigenen Bearbeitung oder an verspäteter Zulieferung?
Diese Frage ist mit Standard-ITSM-Reporting nicht zu beantworten. Denn dafür müsste das Tool die Übergänge zwischen Teams analysieren, nicht den Zustand innerhalb eines Teams. Es müsste messen: Wann kam das Ticket von Team A bei Team B an? Wie lange lag es bei Team A in der Queue? Und korreliert ein Anstieg bei Team A mit einem Anstieg bei Team B – mit Zeitversatz?
Drei Eigenschaften machen Cross-Team-Probleme besonders schwer erkennbar:
Zeitversatz. Wenn Team A heute staut, zeigt sich das bei Team B erst nächste Woche. Wer die Daten zum selben Zeitpunkt betrachtet, sieht zwei unabhängige Probleme. Erst der zeitliche Vergleich über mehrere Wochen zeigt die Kette.
Symptom gleicht Ursache. Team B hat einen wachsenden Backlog und steigende Durchlaufzeiten. Das sieht aus wie ein Kapazitätsengpass. Erst die Frage nach dem Zufluss-Abfluss-Verhältnis zeigt: Team B könnte seine Tickets abarbeiten – wenn sie rechtzeitig ankämen.
Verteilte Verantwortung. Kein einzelner Teamleiter ist für die Kette verantwortlich. Team A optimiert sich, Team B optimiert sich – aber niemand optimiert den Übergang. Dieses Vakuum ist der Kern des Problems.
Was Ticket-Daten über Abhängigkeiten verraten
Die Informationen für eine Cross-Team-Analyse stecken im Eventlog: Jede Zuweisung, jede Übergabe, jeder Statuswechsel. Aus diesen Events lassen sich die Beziehungen zwischen Teams rekonstruieren.
Zulieferungsmatrix
Welches Team übergibt Tickets an welches andere Team? Wie viele pro Woche? Eine einfache Matrix zeigt die Abhängigkeitsstruktur. In einer typischen IT-Organisation mit zehn Teams gibt es nicht hundert gleich starke Verbindungen, sondern fünf bis sieben dominante Zulieferungsbeziehungen. Diese Ketten bestimmen den Großteil der Gesamtdurchlaufzeit.
Backlog-Korrelation
Wenn der Backlog von Team B steigt, sobald der Backlog von Team A steigt – ist das ein Signal. Wenn er sinkt, sobald Team A aufholt – wird es ein starkes Signal. Die Korrelation allein beweist noch keine Kausalität.
Aber in Kombination mit der Zulieferungsmatrix wird das Bild eindeutig. Team A liefert an Team B. Der Backlog von Team B reagiert mit 1–2 Wochen Verzögerung auf den Backlog von Team A. Das ist keine Koinzidenz – das ist eine Kette.
Ein IT-Leiter sieht drei rote Ampeln im Report. Er fragt: Haben wir drei Probleme oder eines? Die Backlog-Korrelation beantwortet diese Frage. Wenn alle drei Backlogs synchron wachsen und Team A den Vorlauf hat, gibt es ein Problem mit drei Symptomen. Nicht drei Probleme.
Impact-Messung über die Kette
Ein einzelner Engpass bei Team A verursacht 3.296 Stunden Impact pro Woche. Aber Team B erbt 2.847 Stunden und Team C weitere 1.204 Stunden. Der Gesamt-Impact über die Kette: 7.347 Stunden. Wer nur Team A betrachtet, unterschätzt den Hebel um mehr als die Hälfte.
Ein konkretes Beispiel: Ein mittelständisches Unternehmen mit fünf IT-Teams stellte seit zwei Monaten steigende Durchlaufzeiten bei drei Teams fest. Die Analyse zeigte eine klare Kette: SAP Basis hatte ein Zufluss-Abfluss-Verhältnis von 2:1. Application Management wartete bei 40 Prozent seiner Tickets auf Zuarbeit von SAP Basis. Change Management wartete auf Freigaben, die durch beide Teams laufen.
Die Lösung adressierte nur den Ursprung: Zwei Kategorien umgeleitet, Zufluss bei SAP Basis minus 25 Prozent. Innerhalb von drei Wochen erholten sich alle drei Teams. Ohne zusätzliches Personal.
Was diese Situation besonders lehrreich macht: Die drei Teamleiter hatten im Eskalationsmeeting alle recht. Jeder arbeitete normal. Keiner war "schuld." Aber ohne die Ketten-Analyse wäre die Reaktion gewesen: Druck auf alle drei Teams. Überstunden für alle. Und die Ursache – der Zufluss bei SAP Basis – wäre unverändert geblieben. Die Kette hätte weiter gestaut.
Drei Prinzipien für Cross-Team-Optimierung
Den Ursprung finden, nicht die Symptome
Die wichtigste Frage bei teamübergreifenden Problemen: Wo beginnt die Kette? Nicht welche Teams betroffen sind, sondern welches Team den Aufstau verursacht. Indikatoren: Welches Team hat zuerst angefangen zu stauen? Welches Team hat das höchste Zufluss-Abfluss-Verhältnis? Welches Team hat die meisten nachgelagerten Abhängigkeiten?
Übergänge messen, nicht nur Zustände
Die Durchlaufzeit eines Tickets besteht zu einem erheblichen Teil aus Übergangszeit – der Zeit zwischen der Übergabe von Team A und dem Bearbeitungsbeginn bei Team B. Diese Übergangszeit taucht in keinem Team-Dashboard auf, weil sie keinem Team zugeordnet ist. Wer sie misst, findet oft den größten Hebel.
Neutral diagnostizieren
Cross-Team-Probleme erzeugen Schuldzuweisungen. "Ihr liefert zu spät." – "Ihr schickt falsch zugewiesene Tickets." Der einzige Ausweg: Eine neutrale Diagnose, die alle Teams gleich behandelt.
Keine Interpretation, nur Zahlen: Zufluss, Abfluss, Wartezeit, Korrelation. Auf dieser Grundlage lässt sich sachlich diskutieren, wo der Hebel liegt. Kein Team muss sich verteidigen – die Daten sprechen.
In der Praxis bewährt sich ein Prinzip: Die Diagnose gehört nicht dem Team, das das Problem hat. Sie gehört dem IT-Leiter, der die Kette sieht. Wenn der IT-Leiter sagt "Die Daten zeigen, dass der Aufstau bei Team A beginnt und Teams B und C betrifft", ist das keine Schuldzuweisung. Es ist eine Strukturaussage. Und sie eröffnet ein Gespräch über Lösungen statt über Schuld.
Das gilt besonders für die Kommunikation zwischen IT und Business. Beide Seiten haben ihre eigene Wahrheit: "Die IT ist zu langsam" und "Wir arbeiten am Limit." Eine Cross-Team-Analyse zeigt die dritte Wahrheit: Das Problem liegt in der Struktur, nicht bei den Menschen. Das ist die Grundlage für ein konstruktives Gespräch. Mehr dazu unter ITSM-Kennzahlen richtig lesen.
Wie Process Radar Cross-Team-Abhängigkeiten erkennt
Process Radar modelliert jede Rolle als Bestand mit Zufluss und Abfluss – wöchentlich. Daraus berechnet das Tool automatisch: Wo staut sich etwas auf? Welche Teams sind über Zulieferungsbeziehungen verbunden? Gibt es eine zeitlich versetzte Korrelation zwischen den Backlogs zweier Teams? Die Ergebnisse erscheinen im Briefing als zusammenhängende Situation: Ursprungsteam, betroffene nachgelagerte Teams, Gesamt-Impact in Stunden und geschätzten Kosten. Die Delegation an den verantwortlichen Teamleiter erfolgt mit einem Klick.
Der häufigste Aha-Moment: "Wir dachten, wir haben drei Probleme. Wir haben eines."
Laden Sie Ihre Ticket-Daten hoch – die erste Analyse zeigt, wo Ihre Ketten hängen.