Zwei Wahrheiten, ein Problem — warum IT-Beschwerden nie aufhören

Die Fachseite beschwert sich. Die IT-Teams erklären. Beide haben Recht — und das ist das Problem.

In fast jeder IT-Organisation gibt es diese Situation: Der Vertrieb beschwert sich, dass CRM-Änderungen Wochen dauern. Das IT-Team zeigt seine Zahlen: Auslastung bei 95 Prozent, Bearbeitungszeit im Rahmen, alle SLAs erfüllt. Beide Seiten haben Daten. Beide Seiten haben Recht. Und trotzdem wird das Problem nicht gelöst.

Das ist kein Kommunikationsproblem. Es ist ein Diagnoseproblem.

Die zwei Perspektiven

Was die Fachseite sieht

Die Fachseite erlebt den Prozess von außen. Sie reicht ein Ticket ein und wartet. Was sie misst — ob bewusst oder unbewusst — ist die Gesamtwartezeit: Vom Einreichen bis zum Abschluss. Wenn das drei Wochen dauert, ist das drei Wochen zu viel. Die Kategorie spielt keine Rolle, die internen Übergaben interessieren nicht. Das Ergebnis zählt.

Wenn die Fachseite sich beschwert, ist die Botschaft klar: "Es dauert zu lange." Das ist eine valide Beobachtung — und sie basiert auf einer validen Metrik: der Gesamtdurchlaufzeit.

Was die IT sieht

Die IT sieht den Prozess von innen. Jedes Team misst seine eigene Bearbeitungszeit, seinen eigenen Backlog, seine eigene SLA-Erfüllung. Und diese Zahlen sehen oft gut aus — weil jedes einzelne Team seinen Teil des Prozesses im Griff hat.

Wenn das Infrastruktur-Team seine Tickets in 4 Stunden bearbeitet und das Application-Team in 6 Stunden, sind beide Teams schnell. Die Frage, die niemand stellt: Was passiert zwischen den Teams? Wie lange wartet das Ticket auf die Übergabe? Wie lange liegt es in der Queue des nächsten Teams, bevor jemand es aufgreift?

Wo das Problem entsteht

Das Problem liegt nicht innerhalb der Teams. Es liegt dazwischen.

Ein typisches Ticket durchläuft in einer mittelgroßen IT-Organisation drei bis fünf Stationen. An jeder Station wird bearbeitet — aber zwischen den Stationen wird gewartet. Diese Wartezeit ist für kein einzelnes Team sichtbar, weil sie in keinem Team-Dashboard auftaucht.

Stellen Sie sich einen Prozess vor, der insgesamt 15 Arbeitstage dauert:

• Team A bearbeitet 4 Stunden
• Wartezeit auf Übergabe an Team B: 3 Tage
• Team B bearbeitet 6 Stunden
• Wartezeit auf Übergabe an Team C: 5 Tage
• Team C bearbeitet 2 Stunden
• Wartezeit auf Rückmeldung an Nutzer: 4 Tage
• Abschluss: 30 Minuten

Die reine Bearbeitungszeit beträgt weniger als 2 Tage. Die Wartezeit beträgt 12 Tage. Kein Team ist zu langsam — aber der Prozess dauert drei Wochen.

Wenn der VP IT im Eskalationsmeeting fragt "Warum dauert das so lange?", kommt von jedem Team die gleiche Antwort: "Bei uns liegt es nicht." Und alle haben Recht.

Warum dieses Muster so stabil ist

Drei Mechanismen halten dieses Muster am Leben.

1. Jedes Team optimiert sich selbst

Teams werden an ihren eigenen Kennzahlen gemessen: Bearbeitungszeit, Backlog-Größe, SLA-Erfüllung. Keine dieser Kennzahlen misst die Übergabezeit zwischen Teams. Also optimiert jedes Team seine Bearbeitungszeit — was richtig und wichtig ist — aber niemand optimiert die Übergaben.

Das Ergebnis: Jedes Team wird schneller, aber der Gesamtprozess wird nicht schneller. Weil die Wartezeit zwischen den Teams den größeren Anteil an der Durchlaufzeit ausmacht als die Bearbeitungszeit innerhalb der Teams.

2. Die Daten stützen beide Seiten

Die Fachseite hat Daten: "Unser Ticket hat 18 Tage gedauert." Die IT hat Daten: "Unsere durchschnittliche Bearbeitungszeit beträgt 5 Stunden." Beide Datensätze sind korrekt. Aber sie messen verschiedene Dinge — und niemand hat die Daten, die beides verbinden.

Was fehlt, ist die Zerlegung der Gesamtdurchlaufzeit in ihre Bestandteile: Bearbeitungszeit pro Team, Wartezeit zwischen Teams, Anzahl der Übergaben. Diese Information existiert in den Ticket-Daten — sie wird nur nicht ausgewertet.

3. Die Lösung erfordert organisatorisches Handeln

Wenn das Problem innerhalb eines Teams läge, könnte das Team es selbst lösen. Aber Übergabezeiten liegen zwischen Teams — und damit in der Verantwortung der Organisation, nicht eines einzelnen Teams. Das erfordert eine andere Art von Entscheidung: Prozessdesign ändern, Routing anpassen, Übergabepunkte reduzieren. Das kann kein Teamleiter allein entscheiden. Es braucht jemanden mit organisatorischer Sicht.

Was eine systemische Diagnose anders macht

Eine systemische Diagnose betrachtet nicht einzelne Teams, sondern den Fluss von Tickets durch die Organisation. Sie beantwortet drei Fragen, die Team-Dashboards nicht beantworten:

Wo entsteht die Wartezeit? Nicht "Welches Team ist langsam?" sondern "An welcher Übergabe warten Tickets am längsten?" Wenn 60 Prozent der Gesamtdurchlaufzeit an einer einzigen Übergabe entstehen, ist das der Hebel — nicht die Bearbeitungszeit der Teams.

Welche Abhängigkeiten verursachen Verzögerungen? Wenn Team B auf Zuarbeit von Team A wartet und Team A gerade andere Prioritäten hat, staut sich der Prozess — ohne dass ein Team "schuld" ist. Die Diagnose zeigt, welche Abhängigkeiten kritisch sind und welche nicht.

Was passiert, wenn ein Team staut? Wenn ein Team vorübergehend überlastet ist, pflanzt sich der Stau über die Übergabepunkte fort. Die Diagnose zeigt, welche nachgelagerten Teams betroffen sind und wie groß der Effekt ist.

Ein typisches Szenario

Ein IT-Leiter bekommt seit Monaten Beschwerden aus dem Einkauf: "Unsere Bestellfreigaben dauern ewig." Das Service-Desk-Team zeigt: durchschnittliche Bearbeitungszeit 2 Stunden, SLA-Erfüllung 94 Prozent. Das ERP-Team zeigt ähnliche Zahlen. Niemand ist zu langsam.

Die systemische Analyse zeigt: Bestellfreigaben durchlaufen im Median 4 Teams. An der Übergabe zwischen Service Desk und ERP-Team warten Tickets im Median 2,5 Tage. An der Übergabe zwischen ERP-Team und Freigabe-Instanz warten sie nochmal 3 Tage. Die reine Bearbeitungszeit beträgt 6 Stunden, die Wartezeit 11 Tage.

Die Lösung: Bestellfreigaben werden als eigene Routing-Kategorie definiert mit einem vereinfachten Pfad: Service Desk klärt direkt mit der Freigabe-Instanz, das ERP-Team wird nur bei technischen Änderungen einbezogen. Ergebnis: Die Durchlaufzeit sinkt von 12 Tagen auf 4 Tage — ohne zusätzliches Personal, ohne Überstunden, ohne Schuldzuweisung.

Drei Schritte zur systemischen Sicht

Schritt 1: Die Gesamtdurchlaufzeit zerlegen. Nicht nur "Wie lange dauert das Ticket?" sondern "Wie verteilt sich die Zeit auf Bearbeitungszeit und Wartezeit?" Wenn mehr als 60 Prozent der Durchlaufzeit Wartezeit ist, liegt das Problem zwischen den Teams, nicht innerhalb der Teams.

Schritt 2: Die kritischen Übergaben identifizieren. An welchen Stellen im Prozess warten Tickets systematisch länger als an anderen? Eine einzelne Übergabe kann 50 Prozent der Gesamtdurchlaufzeit verursachen — und ist mit Team-Dashboards unsichtbar.

Schritt 3: Die Prozessstruktur hinterfragen. Muss das Ticket wirklich durch vier Teams? Kann eine Übergabe eliminiert werden? Kann ein Team direkt mit dem Endkunden kommunizieren statt über Zwischenstationen? Jede eingesparte Übergabe spart die zugehörige Wartezeit.

Der Wert der neutralen Faktengrundlage

Das Schwierigste an systemischen Problemen ist nicht die Lösung — sondern die Diagnose. Solange beide Seiten ihre eigenen Zahlen präsentieren und beide Recht haben, dreht sich die Diskussion im Kreis. Was die Diskussion löst, ist eine gemeinsame Faktengrundlage, die niemandes Position unterstüzt oder angreift, sondern das Problem sichtbar macht: Wo genau im Prozess entsteht die Verzögerung?

Diese Faktengrundlage ändert die Gesprächsebene. Statt "Ihr seid zu langsam" vs. "Wir sind nicht zu langsam" wird die Frage: "Wie reduzieren wir die Wartezeit an dieser Übergabe?" Das ist eine Frage, an der beide Seiten gemeinsam arbeiten können.

Process Radar macht genau diese Stellen sichtbar. Testen Sie es mit Ihren eigenen Daten.

Häufig gestellte Fragen

Warum hören IT-Beschwerden nicht auf, obwohl die Teams gut arbeiten? Weil das Problem zwischen den Teams liegt, nicht innerhalb der Teams. Jedes Team kann seine Bearbeitungszeit optimieren — aber die Wartezeit an Übergabepunkten wird von keinem Team gemessen und von keinem Dashboard angezeigt. Diese Wartezeit macht in vielen Organisationen mehr als 70 Prozent der Gesamtdurchlaufzeit aus.

Wie erkennt man, ob ein Engpass systemisch ist? Drei Indikatoren: Erstens, mehrere Teams zeigen gute Einzelkennzahlen, aber die Gesamtdurchlaufzeit ist hoch. Zweitens, Beschwerden und Begründungen widersprechen sich nicht, führen aber zu keiner Lösung. Drittens, Einzelmaßnahmen (mehr Personal, schnellere Bearbeitung) verbessern die Gesamtsituation nicht spürbar.

Was ist der Unterschied zwischen einem Team-Engpass und einem systemischen Engpass? Ein Team-Engpass liegt innerhalb eines Teams: Zu viele Tickets, zu wenig Kapazität, zu lange Bearbeitungszeit. Ein systemischer Engpass liegt zwischen Teams: Tickets warten an Übergaben, Abhängigkeiten verzögern den Fluss, die Prozessstruktur erzwingt unnötige Umwege. Team-Engpässe sind in Standard-Dashboards sichtbar. Systemische Engpässe erfordern eine Analyse der Beziehungen zwischen Teams.