Kaskadeneffekt in IT-Prozessen: Wenn ein Engpass die ganze Organisation ausbremst

Das SAP-Basis-Team hat einen Engpass. 68 Tickets kommen pro Woche rein, 34 werden abgeschlossen. Der Backlog wächst um 34 Tickets pro Woche. Das ist sichtbar, das steht im Report, das wird adressiert.

Was nicht im Report steht: Das Application Management wartet auf Zuarbeit von SAP Basis. Solange SAP Basis staut, können 40 Prozent der AppMgmt-Tickets nicht abgeschlossen werden. Das Change Management wartet auf Freigaben, die durch SAP Basis laufen. Die Durchlaufzeiten steigen dort ebenfalls — obwohl das Change-Team nichts falsch macht.

Aus einem Engpass werden drei. Aus einem Teamproblem wird ein Organisationsproblem. Das ist der Kaskadeneffekt — und er ist eines der am schwersten zu erkennenden Muster im IT-Service-Management.

Was ein Kaskadeneffekt ist

Ein Kaskadeneffekt entsteht, wenn ein Engpass in einem Team die Arbeitsfähigkeit nachgelagerter Teams beeinträchtigt. Nicht durch direkte Arbeitsüberladung, sondern durch verzögerte Zulieferung.

Das Muster ist einfach: Team A liefert zu an Team B. Wenn Team A staut, bekommt Team B seine Eingangsinformationen später. Team B kann seine eigenen Tickets nicht abschließen, obwohl es Kapazität hätte. Der Backlog von Team B wächst — nicht wegen eigener Langsamkeit, sondern wegen fehlender Zulieferung.

In der Praxis zeigt sich das an einem charakteristischen Bild: Mehrere Teams zeigen gleichzeitig steigende Durchlaufzeiten. Die naheliegende Interpretation — "alle Teams sind zu langsam" — führt zu einer Reaktion, die das Problem verschlimmert: Druck auf alle Teams, Überstunden für alle, Eskalation an alle Teamleiter. Aber die Ursache liegt bei einem einzigen Team.

Warum Kaskadeneffekte unsichtbar bleiben

Drei Gründe machen Kaskadeneffekte besonders schwer erkennbar.

1. Team-Dashboards zeigen keine Abhängigkeiten

Jedes Team sieht seinen eigenen Backlog und seine eigenen Durchlaufzeiten. Was kein Team sieht: Woher kommen die Verzögerungen? Liegt es an der eigenen Bearbeitung oder an verzögerter Zulieferung? Standard-ITSM-Dashboards antworten auf diese Frage nicht — sie zeigen den Zustand innerhalb eines Teams, nicht die Beziehungen zwischen Teams.

Das führt zu einem typischen Muster in Eskalationsmeetings: Jedes Team verteidigt sich mit den eigenen Zahlen ("Unsere Bearbeitungszeit ist stabil"), während der IT-Leiter sieht, dass trotzdem alles langsamer wird. Die Erklärung liegt in den Übergängen — aber die misst niemand.

2. Die Symptome sehen aus wie das Problem

Wenn das Application Management steigende Durchlaufzeiten zeigt, liegt die naheliegende Diagnose bei "AppMgmt hat ein Kapazitätsproblem". Die Reaktion: mehr Kapazität für AppMgmt. Aber wenn die eigentliche Ursache bei SAP Basis liegt, hilft mehr Kapazität bei AppMgmt nicht — die Tickets kommen weiterhin spät an, und die zusätzliche Kapazität steht leer, während auf Zulieferung gewartet wird.

Das ist besonders trickreich, weil die Diagnose "Kapazitätsproblem" technisch korrekt aussieht: Der Backlog wächst, die Durchlaufzeit steigt, das Team ist ausgelastet. Nur die Ursache ist eine andere — und damit auch die Lösung.

3. Zeitliche Verzögerung verschleiert den Zusammenhang

Kaskadeneffekte wirken mit Zeitversatz. Wenn SAP Basis heute staut, zeigt sich das bei AppMgmt erst nächste Woche — wenn die verspäteten Zulieferungen die Bearbeitungskette erreichen. Wer die Daten zum selben Zeitpunkt betrachtet, sieht zwei unabhängige Probleme. Erst der zeitliche Vergleich zeigt den Zusammenhang: Der Aufstau bei AppMgmt folgt dem Aufstau bei SAP Basis mit einer Woche Verzögerung.

Den Ursprung finden — nicht die Symptome

Die entscheidende Frage bei einem Kaskadeneffekt ist nicht "Welche Teams sind betroffen?" sondern "Wo beginnt die Kette?"

Drei Indikatoren helfen:

Zeitliche Reihenfolge. Welches Team hat zuerst angefangen zu stauen? Wenn SAP Basis seit sechs Wochen steigende Backlogs hat und AppMgmt erst seit drei Wochen, liegt die Ursache wahrscheinlich bei SAP Basis.

Zulieferungsbeziehungen. Welche Teams liefern an welche anderen Teams zu? Wenn 40 Prozent der AppMgmt-Tickets eine Zuarbeit von SAP Basis benötigen, ist SAP Basis ein potenzieller Kaskadenauslöser.

Korrelation der Backlogs. Wenn der Backlog von Team B steigt, sobald der Backlog von Team A steigt — und umgekehrt sinkt, wenn Team A aufholt — ist das ein starkes Signal für einen kausalen Zusammenhang.

Ein Praxis-Szenario

Ein mittelständisches Unternehmen mit fünf IT-Teams und rund 300 Tickets pro Woche bemerkt seit zwei Monaten steigende Durchlaufzeiten. Betroffen sind drei Teams: SAP Basis, Application Management und Change Management. Der Standard-Report zeigt bei allen drei Teams erhöhte Backlogs und steigende Bearbeitungszeiten.

Die erste Reaktion: Ein Eskalationsmeeting mit allen drei Teamleitern. Ergebnis: Jeder erklärt, dass sein Team normal arbeitet, aber "von den anderen Teams" zu spät beliefert wird. Ein Fingerzeig-Kreislauf ohne Lösung.

Die Analyse mit Process Radar zeigt ein klares Bild. Im Team-Monitor ist der Zustand jedes Teams auf einen Blick sichtbar: SAP Basis hat ein Inflow-Outflow-Verhältnis von 2:1 — struktureller Aufstau. Application Management und Change Management haben ein Verhältnis von etwa 1.2:1 — leicht erhöhter Backlog, aber kein eigenständiges Kapazitätsproblem.

Die Kausalkette: SAP Basis staut. Tickets, die SAP Basis an Application Management übergibt, kommen im Median 2.3 Tage später als üblich. Application Management kann 40 Prozent seiner Tickets erst bearbeiten, wenn SAP Basis geliefert hat — und wartet. Change Management wartet auf Freigaben, die durch beide Teams laufen, und erbt die Verzögerung.

Process Radar erkennt nicht nur den Engpass, sondern auch welche nachgelagerten Teams betroffen sind. Im Briefing erscheint die Situation als zusammenhängendes Handlungsfeld: "Kapazitätsengpass SAP Basis mit Kaskadeneffekt auf AppMgmt und Change — 4.800 Stunden Gesamt-Impact."

Die Lösung adressiert den Ursprung, nicht die Symptome: Zwei Ticket-Kategorien, die bisher pauschal bei SAP Basis landeten, werden ans spezialisierte SAP-Development-Team umgeleitet. Das reduziert den Inflow bei SAP Basis um 25 Prozent. Innerhalb von drei Wochen sinkt der Backlog — und mit ihm die Durchlaufzeiten bei AppMgmt und Change Management. Ohne zusätzliches Personal. Ohne Überstunden bei den nachgelagerten Teams.

Drei Schritte gegen Kaskadeneffekte

Schritt 1: Zulieferungsbeziehungen kartieren. Welche Teams liefern an welche anderen Teams zu? Das muss keine perfekte Prozesslandkarte sein — eine einfache Matrix "Team A liefert an Team B" genügt. Prüfe für die letzten Monate: Welche Teams haben gleichzeitig steigende Backlogs?

Schritt 2: Kausalkette identifizieren. Lade deine Ticket-Daten als CSV in Process Radar hoch. Das Tool erkennt Kaskadeneffekte automatisch und zeigt im Team-Monitor den Zustand jedes Teams auf einen Blick — inklusive der Frage, ob ein Backlog eigenständig oder durch einen vorgelagerten Engpass verursacht wird.

Schritt 3: Ursprung adressieren. Nicht alle betroffenen Teams gleichzeitig optimieren, sondern den Ursprung der Kaskade finden und dort ansetzen. Das kann eine Routing-Änderung sein, eine Kapazitätsaufstockung oder eine Neuverteilung von Kategorien. Der Effekt pflanzt sich automatisch in die nachgelagerten Teams fort — genauso wie zuvor das Problem.

Warum die richtige Diagnose entscheidend ist

Die Kosten einer falschen Diagnose bei Kaskadeneffekten sind besonders hoch. Wer drei Teams gleichzeitig verstärkt, investiert dreifach — obwohl der Hebel bei einem einzigen Team liegt. Wer das richtige Team identifiziert, löst mit einer Maßnahme drei Probleme.

Das gilt auch umgekehrt: Wenn ein Team verstärkt wird, das gar nicht die Ursache ist, verschwenden die zusätzlichen Kapazitäten. Das Team hat mehr Leute — aber wartet trotzdem auf Zulieferung. Die Durchlaufzeit verbessert sich nicht. Die Investition verpufft.

Die Daten für die richtige Diagnose existieren in jedem ITSM-System. Man muss sie nur so lesen, dass die Beziehungen zwischen Teams sichtbar werden — nicht nur der Zustand innerhalb jedes Teams.

Fazit

Ein Kaskadeneffekt lässt drei Probleme wie drei unabhängige Probleme aussehen — obwohl es nur eines ist. Wer den Ursprung findet und dort ansetzt, löst mit einer Maßnahme die gesamte Kette. Die Frage ist nicht "Welches Team ist zu langsam?" sondern "Wo beginnt der Stau?"

Häufig gestellte Fragen

Was ist ein Kaskadeneffekt im IT-Service-Management? Ein Kaskadeneffekt entsteht, wenn ein Engpass in einem Team die Arbeitsfähigkeit nachgelagerter Teams beeinträchtigt. Das Ursprungsteam staut Tickets — und Teams, die auf Zulieferung dieses Teams angewiesen sind, können ihre eigenen Tickets nicht abschließen. Der Effekt pflanzt sich über die Zulieferungskette fort und kann dazu führen, dass drei oder mehr Teams gleichzeitig steigende Durchlaufzeiten zeigen, obwohl die Ursache bei einem einzigen Team liegt.

Wie erkennt man den Ursprung eines Ticket-Rückstaus? Drei Indikatoren helfen: Erstens die zeitliche Reihenfolge — welches Team hat zuerst angefangen zu stauen? Zweitens die Zulieferungsbeziehungen — welche Teams sind auf Zuarbeit welcher anderen Teams angewiesen? Drittens die Korrelation der Backlogs — steigt der Backlog von Team B immer dann, wenn der Backlog von Team A steigt? Tools wie Process Radar identifizieren diese Zusammenhänge automatisch aus den Ticket-Daten.

Kann ein einzelner Engpass die gesamte IT-Organisation verlangsamen? Ja, wenn der Engpass an einer zentralen Stelle in der Zulieferungskette liegt. Ein Team, das vielen anderen Teams zuarbeitet — etwa ein SAP-Basis-Team oder ein zentrales Identity-Management-Team — kann bei Kapazitätsengpässen einen Kaskadeneffekt auslösen, der die gesamte Organisation betrifft. Je zentraler das Team in der Zulieferungsstruktur, desto größer der potenzielle Kaskadeneffekt.