Warum Ihr bestes Team das langsamste ist

Nils Heitmann hatte einen Auftrag. Der CIO der Westpark Energie AG – einem Energieversorger mit 3.500 Mitarbeitern und einem IT-Support aus fünf Teams – wollte wissen, warum die Durchlaufzeiten im Support seit zwei Quartalen stiegen. Nicht dramatisch, aber stetig. Die SLA-Quote lag noch im grünen Bereich, aber der Trend war eindeutig.

"Finde heraus, wo es hakt", hatte der CIO gesagt. "Und dann fix es."

Nils war seit acht Jahren bei Westpark, davon drei als Service Delivery Manager. Er kannte die Teams, kannte die Prozesse, kannte die Zahlen. Dachte er.

Das Paradox

Nils zog die Statistiken der letzten sechs Monate. Fünf Teams, jeweils mit Durchlaufzeit, Ticketvolumen und Abschlussquote. Die üblichen KPIs.

Vier Teams lagen im erwartbaren Bereich. Normale Schwankungen, saisonale Effekte, nichts Auffälliges.

Dann das fünfte Team: die Infrastruktur-Spezialisten. Vier Agents, durchschnittliche Betriebszugehörigkeit elf Jahre. Das erfahrenste Team im gesamten Support. Komplex-Tickets – Netzwerksegmentierung, Firewall-Konfigurationen, Storage-Migration – gingen an sie. Nur an sie.

Ihre Durchlaufzeit: 27 Stunden im Median. Doppelt so lang wie jedes andere Team.

Nils' erster Reflex war: Die sind zu langsam. Vier Leute, die seit über einem Jahrzehnt dasselbe machen – und die langsamsten in der ganzen Organisation?

Er klickte auf die Einzeltickets. Firewall-Regeländerung für eine neue Applikation: gelöst in 45 Minuten. Storage-Erweiterung für das Data Warehouse: gelöst in 2 Stunden. VPN-Tunnel zu einem externen Dienstleister: gelöst in 90 Minuten.

Die Bearbeitungszeiten waren schnell. Die Agents wussten, was sie taten. Keine Rückfragen, keine Irrwege, keine Fehler. Technisch war das Team exzellent.

Aber die Tickets warteten. Im Schnitt 22 Stunden, bevor jemand sie überhaupt anschaute. 22 Stunden Wartezeit, 5 Stunden Bearbeitungszeit, 27 Stunden Durchlaufzeit.

22 Stunden. In der Queue. Bei einem Team aus vier Experten.

Die Spurensuche

Nils schaute genauer hin. Drei Datenpunkte fielen auf.

Erstens: die parallele Arbeit. Jeder Agent im Infrastruktur-Team hatte im Schnitt 12 Tickets gleichzeitig in Bearbeitung. Bei den anderen Teams lag der Wert zwischen 4 und 6. Zwölf parallele Tickets pro Agent – das bedeutete ständige Kontextwechsel, ständig offene Fenster, ständig halb fertige Lösungen.

Zweitens: die Auslastung. Das Team war zu 94% ausgelastet. Auf den ersten Blick: vorbildlich. Kein Leerlauf, keine vergeudete Kapazität. In einem Management-Report hätte das gut ausgesehen.

Nils erinnerte sich an etwas, das er vor Jahren in einem Operations-Seminar gelernt hatte. Etwas über den Zusammenhang zwischen Auslastung und Wartezeiten. Dass der Zusammenhang nicht linear war, sondern ... wie hieß das? Eine Hyperbel.

Er rechnete nach. Bei 80% Auslastung lag der sogenannte Auslastungsfaktor bei 4. Bei 90% bei 9. Bei 94% bei – er tippte es in den Taschenrechner – 15,7.

Fast sechzehnmal so viel Wartezeit wie bei 50% Auslastung. Nicht ein bisschen mehr. Sechzehn mal mehr.

Nils lehnte sich zurück.

Drittens: der Inflow. Woher kamen die Tickets? Nils filterte nach Herkunft. Das Ergebnis: 60% der Tickets kamen aus den anderen Support-Teams – eskaliert, weil "Infrastruktur zuständig". 25% kamen direkt vom Service Desk (L1-Eskalation). 15% waren Change Requests aus der Fachabteilung.

Jedes andere Team im Haus, das ein Ticket nicht zuordnen konnte oder nicht lösen wollte, schickte es an die Infrastruktur-Spezialisten. Weil die es konnten. Weil die es immer konnten.

Das Opfer des eigenen Erfolgs

Nils verstand jetzt das Paradox. Das Infrastruktur-Team war nicht langsam. Es war überflutet.

Die Mechanik war simpel: Das Team war das einzige, das bestimmte Ticket-Typen bearbeiten konnte. Also eskalierte jedes andere Team dorthin, sobald ein Ticket auch nur entfernt nach Infrastruktur aussah. Kein böser Wille – rationales Verhalten. Warum sich mit einem Netzwerk-Problem abmühen, wenn es ein Team gibt, das es in 45 Minuten löst?

Das Problem war kumulativ. Jedes einzelne eskalierte Ticket war vertretbar. In der Summe ergab sich ein Inflow, der die Kapazität des Teams um ein Drittel überstieg.

Und je besser das Team arbeitete – je schneller es die Tickets löste, je weniger Rückfragen es stellte, je zuverlässiger es ablieferte – desto mehr Tickets wurden dorthin geschickt. Ein sich selbst verstärkender Kreislauf.

Nils kannte das Phänomen aus einem anderen Kontext. Bei Westpark gab es eine Kollegin in der Buchhaltung, die Excel-Makros bauen konnte. Irgendwann baute sie für die halbe Firma Makros – nicht weil es zu ihrer Stelle gehörte, sondern weil sie es konnte und niemand sie daran hinderte. Bis sie in Elternzeit ging und plötzlich dreißig Prozesse stillstanden, die niemand dokumentiert hatte.

Beim Infrastruktur-Team war es dasselbe Muster, nur mit Tickets statt mit Makros.

Drei Maßnahmen

Nils schlug dem CIO keine Personalaufstockung vor. Das Budget war ohnehin knapp, und er war sich nicht sicher, ob mehr Leute das Problem lösen oder nur langsamer wachsen lassen würden.

Stattdessen drei Maßnahmen.

Maßnahme 1: WIP-Limit.

Maximal 6 parallele Tickets pro Agent. Hart, keine Ausnahmen.

Rainer Kolbe, der Senior im Infrastruktur-Team, protestierte. "Wenn ich nur 6 Tickets gleichzeitig haben darf, liegen die anderen in der Queue und warten."

"Genau", sagte Nils. "Aber die Wartezeit in der Queue ist transparent. Jeder sieht, dass da 20 Tickets warten. Im Moment hast du 12 Tickets gleichzeitig offen, und die Wartezeit ist unsichtbar – sie versteckt sich in deiner persönlichen Arbeitsliste."

Das WIP-Limit tat etwas Wichtiges: Es machte den Engpass sichtbar. Statt 12 halb bearbeiteter Tickets pro Agent gab es 6 Tickets in Bearbeitung und eine wachsende Queue. Die wachsende Queue war ein Signal an die Organisation – nicht an das Team.

Bei einer Queue-Tiefe von 24 Tickets und einem Durchsatz von 4 pro Stunde ergab sich eine Wartezeit von 6 Stunden. Vorher waren es bei einem WIP von 48 (12 pro Agent × 4 Agents) und demselben effektiven Durchsatz rechnerisch 12 Stunden – nur dass sie sich als "Bearbeitungszeit" tarnten, weil die Tickets formal in Bearbeitung waren.

Maßnahme 2: Skill Sharing.

Die häufigsten Infrastruktur-Tickets waren keine Raketenwissenschaft. VPN-Konfigurationen, DNS-Einträge, Standard-Firewall-Regeln – Aufgaben, die ein erfahrener L2-Agent nach einer Woche Einarbeitung selbst lösen konnte.

Nils identifizierte die fünf häufigsten Ticket-Kategorien, die an das Infrastruktur-Team eskaliert wurden. Drei davon konnten mit überschaubarem Schulungsaufwand auf zwei Agents im Netzwerk-Operations-Team übertragen werden.

Das Ziel war nicht, das Infrastruktur-Team überflüssig zu machen. Das Ziel war, den Inflow um 30% zu reduzieren – von 48 Tickets pro Woche auf 34. Damit die vier Spezialisten ihre Kapazität für die Tickets nutzen konnten, bei denen sie tatsächlich unersetzlich waren.

Maßnahme 3: Rückeskalation.

Bisher war Eskalation eine Einbahnstraße. Wenn ein Ticket beim Infrastruktur-Team landete, blieb es dort – auch wenn es sich als Standard-L2-Aufgabe herausstellte. Kein Agent wollte den Aufwand der Rückgabe, und kein Team wollte ein zurückgeschicktes Ticket annehmen.

Nils führte ein formales Rückeskalations-Verfahren ein. Das Infrastruktur-Team konnte Tickets mit einer standardisierten Begründung an das eskalierende Team zurückgeben: "Kein Infrastruktur-Problem – Standard-L2-Aufgabe, Kategorie X." Das eskalierende Team musste das Ticket annehmen.

In den ersten zwei Wochen kamen 15% der Tickets zurück. Nach vier Wochen hatten die eskalierenden Teams gelernt, genauer zu prüfen, bevor sie eskalierten. Die Quote sank auf 5%.

Acht Wochen später

Die Zahlen nach acht Wochen:

Auslastung des Infrastruktur-Teams: von 94% auf 76%. Der Auslastungsfaktor sank von 15,7 auf 3,2. Die Wartezeit pro Ticket fiel von 22 Stunden auf 7 Stunden.

Durchlaufzeit des Infrastruktur-Teams: von 27 Stunden auf 12 Stunden. Minus 56%.

Gesamtdurchlaufzeit über alle Teams: minus 22%. Weil Tickets, die vorher beim Infrastruktur-Team standen und auf nachgelagerte Schritte blockierten, jetzt schneller durchflossen.

Ein unerwarteter Effekt: Die Zufriedenheit im Infrastruktur-Team stieg messbar. Nicht weil die Arbeit leichter war, sondern weil der permanente Druck von 50 offenen Tickets pro Agent nachgelassen hatte. Die Agents arbeiteten konzentrierter und machten weniger Fehler. Die Reopening-Rate sank um ein Drittel.

Der Aha-Moment

Nils präsentierte die Ergebnisse im monatlichen IT-Leadership-Meeting. Der CIO schaute auf die Zahlen und sagte: "Wir haben die Durchlaufzeit um 22% gesenkt, ohne einen einzigen neuen Mitarbeiter einzustellen?"

"Richtig. Wir haben nicht Kapazität aufgebaut, sondern Inflow umverteilt."

"Und das schnellste Team hat jetzt die kürzeste Durchlaufzeit?"

Nils schüttelte den Kopf. "Das schnellste Team war schon vorher das schnellste – bei der reinen Bearbeitungszeit. Es war nur das langsamste bei der Wartezeit. Und die Wartezeit war das Ergebnis eines Inflows, den das Team nicht kontrollieren konnte."

Er zögerte, dann sagte er den Satz, den er sich auf der Heimfahrt zurechtgelegt hatte: "Effizienz und Auslastung sind nicht dasselbe. Manchmal muss man ein Team entlasten, um den Gesamtprozess zu beschleunigen."

Der CIO nickte. Langsam. "Das ist kontraintuitiv."

"Ja", sagte Nils. "Aber die Mathematik ist eindeutig."

Was dahintersteckt

Nils' Geschichte ist fiktiv. Das Muster ist es nicht.

In vielen IT-Organisationen gibt es ein Team – manchmal das erfahrenste, manchmal das spezialisierteste – das zum Auffangbecken für alles wird, was andere Teams nicht lösen können oder wollen. Die Folge ist chronische Überlastung, die sich als "hohe Auslastung" tarnt und in Management-Reports wie Produktivität aussieht.

Dahinter stehen drei Mechanismen, die in der Warteschlangentheorie gut verstanden sind:

Erstens: Wartezeiten steigen nicht linear mit der Auslastung, sondern exponentiell. Die Details dieses Zusammenhangs beschreiben wir im Artikel über die Auslastungsfalle.

Zweitens: Mehr parallele Arbeit (höherer WIP) verlängert die Durchlaufzeit, nicht verkürzt sie. Der Zusammenhang zwischen Queue-Tiefe, Durchsatz und Verweildauer folgt einer simplen Formel – beschrieben in unserem Artikel über Little's Law.

Drittens: Ein Engpass an einer Stelle des Systems beeinflusst alle nachgelagerten Schritte. Die Theory of Constraints erklärt, warum Kapazität an der falschen Stelle wirkungslos ist – und wie man die richtige Stelle findet. Mehr dazu im Artikel über Engpass-Management im IT-Support.

Die Lösung ist selten mehr Personal. Häufiger ist es eine Kombination aus Inflow-Kontrolle (weniger reinlassen), WIP-Limits (weniger gleichzeitig bearbeiten) und Skill-Distribution (die Last auf mehr Schultern verteilen).

Manchmal muss man das beste Team langsamer füttern, damit es schneller liefert.

Zusammenfassung

Das erfahrenste Team in einer IT-Organisation hat häufig die längsten Durchlaufzeiten – nicht wegen mangelnder Kompetenz, sondern wegen unkontrolliertem Inflow. Wenn jedes andere Team dorthin eskaliert, übersteigt der Zufluss die Kapazität, die Auslastung schießt über 90%, und die Wartezeiten explodieren. Die Lösung liegt nicht in mehr Personal, sondern in WIP-Limits, Skill Sharing und kontrollierten Rückeskalationen.

Weiterführende Quellen

• Hopp, W.J. & Spearman, M.L. (2011): Factory Physics. 3. Aufl., Waveland Press.
• Goldratt, E.M. (1984): The Goal. North River Press.
• Anderson, D.J. (2010): Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
• Reinersten, D.G. (2009): The Principles of Product Development Flow. Celeritas Publishing.