Two for One: Je besser jedes Team wird, desto schlechter läuft das System

In den meisten Organisationen sind die Teams nicht das Problem. Einzelne Abteilungen sind oft gut geführt, fokussiert und bemüht, ihren Job ordentlich zu machen. Und trotzdem bleibt die End-to-End-Performance hinter den Erwartungen zurück. Projekte stocken. Kunden warten. Übergaben scheitern. Die Zahlen sehen in jedem Teambericht gut aus — aber der übergeordnete Prozess liefert nicht, was er sollte.

Das ist das Paradox der lokalen Optimierung. Wenn jeder Teil eines Systems unabhängig optimiert wird, kann das System als Ganzes trotzdem underperformen. Manchmal macht eine bessere lokale Effizienz den übergreifenden Prozess sogar schlechter.

In dieser Ausgabe von Two for One schauen wir uns an, warum lokale Optimierung eine der häufigsten und am wenigsten sichtbaren Ursachen für Prozessversagen ist — und welche zwei strukturellen Hebel Organisationen helfen, von fragmentierter Performance zu echter End-to-End-Prozessperformance zu wechseln.

Warum lokale Optimierung zu systemweitem Versagen führt

Die Logik der lokalen Optimierung ist intuitiv. Organisationen werden aus guten Gründen in Abteilungen gegliedert. Verschiedene Teams bringen unterschiedliches Know-how mit. Spezialisierung verbessert die Qualität. Das Messen der Leistung jeder Einheit schafft Verantwortlichkeit. Das sind solide Management-Prinzipien — bis zu einem gewissen Punkt.

Das Problem beginnt, wenn jedes Team beginnt, nur seine eigenen Metriken zu optimieren, ohne Sicht auf das, was vor oder nach seinem Schritt passiert. Ein Einkaufsteam, das seine eigene Bearbeitungszeit reduziert, kann einen Bottleneck weiter unten erzeugen, indem es zu viele Vorgänge gleichzeitig freigibt. Ein Sales-Team, das seine Conversion Rate maximiert, kann eine Lieferfunktion überlasten, die für dieses Volumen nie ausgelegt war. Ein Support-Team, das Tickets schnell schließt, adressiert vielleicht nicht die Ursachen, die kontinuierlich neue Tickets generieren.

Keines dieser Teams macht isoliert betrachtet etwas falsch. Jedes reagiert rational auf die Anreize und Metriken, die es erhalten hat. Aber die kumulierte Wirkung all dieses rationalen lokalen Verhaltens ist ein System, das nicht wie beabsichtigt funktioniert. Arbeit staut sich an Übergabepunkten. Prioritäten kollidieren zwischen Teams. Ressourcen fließen in lokale Erfolge auf Kosten des Gesamtdurchsatzes.

Das ist keine neue Erkenntnis — Operations Management und Systemdenken beschreiben diese Dynamik seit Jahrzehnten. Und trotzdem bleibt es eines der hartnäckigsten Probleme in der Praxis, gerade weil es aus jeder einzelnen Perspektive so schwer zu erkennen ist. Jedes Team performt. Das System nicht. Und die Lücke zwischen diesen beiden Realitäten bleibt oft unbearbeitet.

Wenn lokale Performance zum eigentlichen Problem wird

Das klarste Zeichen dafür, dass lokale Optimierung das System belastet, ist ein Muster, das in vielen Organisationen auftaucht: Jedes Team meldet Verbesserungen, aber die End-to-End-Durchlaufzeiten werden nicht kürzer. Die Kundenzufriedenheit steigt nicht. Nacharbeit und Eskalationen häufen sich weiterhin. Kosten steigen trotz Effizienzgewinnen in einzelnen Teams.

Was passiert: Verbesserungen innerhalb eines Schritts übertragen sich nicht auf den Gesamtprozess. Sie werden von Puffern, Warteschlangen oder falsch ausgerichteten Prioritäten an der nächsten Übergabe absorbiert. Oder sie erzeugen neuen Druck, der sich an anderer Stelle im System materialisiert.

Ein weiteres deutliches Signal ist Mess-Fragmentierung. Wenn jedes Team seine eigenen KPIs trackt, die nicht mit einer gemeinsamen Definition verbunden sind, was der End-to-End-Prozess liefern soll, gibt es keine organisatorische Sicht darauf, wo Wert tatsächlich erzeugt oder vernichtet wird. Teams werden sehr gut darin, sich selbst zu messen — und sehr schlecht darin zu verstehen, wozu sie gemeinsam beitragen.

Hier wird die Unterscheidung zwischen Prozesseffizienz und Prozesseffektivität wichtig. Ein Team kann hocheffizient sein — Inputs schnell verarbeiten, Fehler minimieren, SLAs einhalten — während der Gesamtprozess ineffektiv bleibt, weil die richtigen Outputs nicht zur richtigen Zeit in der richtigen Reihenfolge entstehen. Effizienz auf lokaler Ebene garantiert keine Effektivität auf Systemebene. In komplexen, cross-funktionalen Prozessen arbeitet sie oft aktiv dagegen.

Die versteckten Kosten lokaler Optimierung in der End-to-End-Prozessperformance

Die Kosten dieses Musters sind real, aber sie tauchen in keinem einzelnen Team-Dashboard auf.

Der direkteste Kostentreiber ist verschwendete Durchsatzkapazität. Wenn Teams unabhängig optimieren, erzeugen sie lokale Überschüsse und Engpässe, die nicht zueinander passen. Ein Schritt wird schneller fertig, als der nächste absorbieren kann. Arbeit staut sich an Übergaben. Die Gesamtdurchlaufzeit bleibt lang, obwohl jeder einzelne Schritt kürzer wurde. Das ist eine der Kerneinsichten aus Lean und Flow-based Operations: Die Geschwindigkeit des Systems wird nicht durch die schnellsten Schritte bestimmt, sondern durch die Engpässe zwischen ihnen.

Hinzu kommen Koordinationskosten, die wachsen, wenn jedes Team eigene Workarounds für die Lücken zwischen Schritten aufbaut. Shadow Processes entstehen. Informelle Eskalationspfade entwickeln sich. Menschen verbringen immer mehr Zeit mit Aktivitäten, die nur existieren, um schlechtes Interface-Design zu kompensieren — doppeltes Prüfen, manuelles Re-Routing, Datennacherfassung.

Aus einer Business-Process-Management-Perspektive ist das ein strukturelles Problem, kein verhaltensbasiertes. Die Teams versagen nicht aus Mangel an Einsatz oder Disziplin. Sie versagen, weil die Prozessarchitektur nicht am System ausgerichtet wurde. Ownership ist fragmentiert. Metriken sind siloisiert. Niemand hat das Mandat, den Flow der Arbeit über den gesamten Prozess hinweg zu steuern. Das System als Ganzes ist — faktisch — ungeführt, auch wenn jeder seiner Teile sorgfältig gemanagt wird.

Zwei praktische Hebel für End-to-End-Prozessperformance

Es gibt viele Wege, lokale Optimierung zu adressieren, aber zwei strukturelle Änderungen haben konsistent den größten Einfluss. Der erste ist die Einführung von End-to-End-Prozessverantwortung. Der zweite ist das Ersetzen siloisierter Metriken durch systemweite Performance-Kennzahlen.

End-to-End-Prozessverantwortung schaffen

Der direkteste Weg, lokaler Optimierung entgegenzuwirken, ist die Schaffung einer Rolle oder Funktion, die explizit für die Performance des gesamten Prozesses verantwortlich ist — nicht nur für einen Schritt darin.

In den meisten Organisationen existiert diese Art von Ownership in der Praxis nicht. Einzelne Teams besitzen ihr Stück des Workflows, und Senior Leadership verantwortet die übergeordneten Business-Outcomes. Aber der Raum dazwischen — das Design und die Performance des cross-funktionalen Prozesses, der diese Teams verbindet — ist oft niemandes explizite Verantwortung. Er wird informell gemanagt, durch Koordinations-Meetings und Eskalationsketten, aber er hat keinen designierten Owner, der strukturelle Entscheidungen über den Prozessablauf treffen kann.

End-to-End-Prozessverantwortung ändert das. Sie schafft eine Funktion — oft als Process Owner, Value Stream Manager oder Cross-functional Lead bezeichnet — deren primäre Verantwortung die Performance des Prozesses von Anfang bis Ende ist. Diese Rolle ersetzt nicht das Team-Management. Sie fügt eine Governance-Ebene hinzu, die sicherstellt, dass die Übergaben zwischen Teams aktiv gemanagt werden statt dem Zufall überlassen zu bleiben.

Wie sieht das in der Praxis aus? Ein End-to-End Process Owner hat die Autorität und die Sichtbarkeit, um zu erkennen, wo Arbeit über den Prozess hinweg stecken bleibt — nicht nur innerhalb eines Schritts. Er kann Übergaben neu gestalten, Prioritätskonflikte zwischen Teams lösen und sicherstellen, dass lokale Verbesserungen so umgesetzt werden, dass sie den Gesamtfluss stärken statt fragmentieren. Er kann auch die organisatorische Stimme des Kunden innerhalb des Prozesses sein — und die Aufmerksamkeit darauf lenken, ob die richtigen Outputs entstehen, nicht nur ob jeder interne Schritt seine Ziele erfüllt.

Organisationen, die echte End-to-End-Prozessverantwortung einführen, stellen oft fest, dass sich Probleme auflösen, die jahrelang durch Eskalationswege gekreist sind. Die Probleme waren nicht neu. Neu war die Existenz von jemandem mit der Autorität und dem cross-funktionalen Blick, sie strukturell statt reaktiv anzugehen.

Ein nützliches Prüfprinzip: Wenn niemand in deiner Organisation ohne Zögern beantworten kann, wer für die Performance des gesamten Prozesses End-to-End verantwortlich ist — das ist die Lücke.

Metriken am System ausrichten, nicht am Silo

Der zweite Hebel ist eine Veränderung dessen, was gemessen wird und wie. Lokale Optimierung ist im Kern ein Messproblem. Teams optimieren, wofür sie gemessen werden. Wenn die Messung an der Teamgrenze aufhört, hört die Optimierung dort auch auf.

Das adressieren heißt: systemweite Metriken einführen, die die Performance des Prozesses als Ganzes abbilden — Metriken, die kein einzelnes Team unilateral verbessern kann, weil sie davon abhängen, wie gut alle Teile zusammenarbeiten. End-to-End-Durchlaufzeit ist ein Beispiel. Kundenergebnis-Kennzahlen ein weiteres. Ebenso First-Time-Right-Quoten über den gesamten Prozess hinweg, oder Durchsatz gemessen am System-Output statt an jedem einzelnen Schritt.

Entscheidend ist, dass diese Metriken für alle Teams im Prozess sichtbar sein müssen — nicht nur für die Senior Leadership. Wenn Teams sehen können, wie ihre lokalen Entscheidungen die Gesamtperformance beeinflussen, verändert sich die Natur der Konversation. Trade-offs, die bisher unsichtbar waren — mein Team wird schneller, aber der nächste Schritt wird überlastet — werden explizit und können diskutiert und gelöst werden, bevor sie Probleme erzeugen.

Das bedeutet nicht, lokale Metriken aufzugeben. Team-Level-KPIs bleiben für das operative Management nützlich. Aber sie müssen durch systemweite Kennzahlen ergänzt werden, die allen ein gemeinsames Bild davon geben, ob der Prozess als Ganzes funktioniert. Ohne dieses gemeinsame Bild basiert Koordination auf Meinung und Verhandlung. Mit ihm kann Koordination auf Evidenz basieren.

Ein nützliches Prinzip: Wenn deine Organisation keine Metrik hat, die die Performance des gesamten Prozesses misst — eine, die kein Team durch eigene Zahlen verbessern kann — dann hast du keine systemweite Performance-Sicht. Du hast eine Sammlung von Team-Level-Performance-Sichten. Das ist nicht dasselbe, und es als äquivalent zu behandeln ist einer der zuverlässigsten Wege, lokale Optimierung dauerhaft aufrechtzuerhalten.

Food for Thought

Wenn Organisationen lokale Optimierung ehrlich beginnen zu hinterfragen, tauchen einige Fragen auf, die sich lohnen, bei ihnen zu verweilen.

Hat deine Organisation eine klare, gemeinsame Definition dessen, was der End-to-End-Prozess liefern soll — und wird diese Definition von jemandem anderen als der Senior Leadership gehalten? Wer in deiner Organisation ist explizit verantwortlich für die Performance des gesamten cross-funktionalen Prozesses, und welche Autorität hat diese Person, strukturelle Änderungen vorzunehmen? Wenn ein Team seine eigenen Metriken verbessert, wie verifiziert die Organisation, dass sich der Gesamtprozess ebenfalls verbessert? Sind die KPIs, an denen deine Teams gemessen werden, darauf ausgelegt, lokale Effizienz, systemische Effektivität oder beides zu fördern? Und wenn Prozessprobleme eskaliert werden — werden sie auf der strukturellen Ebene gelöst, oder kehren sie als dieselben Probleme in leicht veränderter Form zurück?

Diese Fragen sind wichtig, weil sie offenbaren, ob die Organisation einen Prozess managt oder eine Sammlung von Teams, die zufällig miteinander verbunden sind. Der Unterschied klingt gering, aber er entscheidet in der Praxis darüber, ob Verbesserungsbemühungen zu systemweiten Ergebnissen führen oder einfach verschieben, wo die Probleme auftauchen.

Fazit: Optimiere das System, nicht nur seine Teile

Wenn jedes Team gut performt, aber das System weiter underperformt, liegt die Ursache selten an Einsatz oder Talent. Meistens wurde das System nie formal geführt — nur seine Teile wurden geführt.

Zwei strukturelle Hebel sind besonders effektiv. Der erste ist die Einführung echter End-to-End-Prozessverantwortung, die eine Rolle schafft mit der Autorität und Sichtbarkeit, den gesamten Prozess statt nur eines Schritts darin zu managen. Der zweite ist die Einführung systemweiter Metriken, die allen Teams eine gemeinsame Sicht auf die Gesamtperformance geben — sodass lokale Entscheidungen im Bewusstsein ihrer Wirkung auf das Ganze getroffen werden können.

Das Ziel ist nicht, das Team-Level-Performance-Management abzuschaffen. Es geht darum, eine Governance-Ebene hinzuzufügen, die sicherstellt, dass lokale Performance und System-Performance tatsächlich verbunden sind — sodass wenn Teams sich verbessern, sich der Prozess mit ihnen verbessert.

Das ist das tiefere Versprechen von Business Process Management in komplexen, cross-funktionalen Umgebungen. Es geht nicht darum, jeden Schritt enger zu kontrollieren. Es geht darum, das System so zu gestalten, dass der Erfolg jedes Schritts zum Ergebnis beiträgt, das der gesamte Prozess zu liefern gebaut wurde.

FAQ

Was ist lokale Optimierung und warum ist sie ein Problem in Geschäftsprozessen?

Lokale Optimierung bedeutet, dass jedes Team oder jede Abteilung die eigenen Performance-Metriken verbessert, ohne die Auswirkungen auf den Gesamtprozess zu berücksichtigen. Sie wird zum Problem, weil individuelle Verbesserungen an anderer Stelle Bottlenecks, falsch ausgerichtete Prioritäten und verschwendete Kapazitäten erzeugen können — und die End-to-End-Prozessperformance unverändert bleibt oder sich verschlechtert.

Warum kann ein gut performendes Team trotzdem zu einem schlechten Gesamtprozess beitragen?

Teams werden an ihren eigenen Outputs gemessen und optimieren entsprechend. Ein Prozess ist jedoch ein verbundenes System — Effizienz in einem Schritt garantiert keine Effektivität auf Systemebene. Wenn Übergaben schlecht gestaltet sind, Metriken siloisiert sind oder niemand den gesamten Flow verantwortet, werden lokale Performance-Gewinne absorbiert, bevor sie dem Kunden oder dem Gesamtergebnis zugutekommen.

Was ist End-to-End-Prozessverantwortung und warum ist sie wichtig?

End-to-End-Prozessverantwortung weist die explizite Verantwortung für die Performance des gesamten cross-funktionalen Prozesses einer einzigen Rolle oder Funktion zu — nicht nur einem Schritt. Sie ist wichtig, weil ohne diese Verantwortung die Übergaben zwischen Teams ungemanagt bleiben und strukturelle Probleme fortbestehen, unabhängig davon, wie gut einzelne Teams performen.

Wie unterscheiden sich systemweite Metriken von Team-Level-KPIs?

Team-Level-KPIs messen, wie gut eine einzelne Einheit ihre spezifischen Aufgaben erfüllt. Systemweite Metriken messen die Performance des gesamten Prozesses — wie End-to-End-Durchlaufzeit, First-Time-Right-Quoten oder Kundenergebnisse — die kein einzelnes Team unilateral verbessern kann. Beide sind notwendig, aber Organisationen, die sich nur auf Team-KPIs verlassen, haben keine verlässliche Sicht darauf, ob der Gesamtprozess funktioniert.

Wie erkennen Organisationen, ob lokale Optimierung zu systemweitem Versagen führt?

Typische Signale sind: Teams melden Verbesserungen, während End-to-End-Durchlaufzeiten gleich bleiben oder steigen; wachsende Koordinationskosten und Shadow Processes an Team-Übergaben; immer wiederkehrende Eskalationen ohne strukturelle Lösung; und das Fehlen jeglicher Metrik, die die Performance des gesamten Prozesses abbildet. Wenn diese Muster gemeinsam auftreten, ist lokale Optimierung fast immer ein wesentlicher Faktor.