Warum übergreifende BPMN-Prozesse gefährlich für moderne Organisationen sind

In vielen Unternehmen gelten übergreifende, sogenannte Ende-zu-Ende-Prozesse in BPMN noch immer als Königsweg der Prozessoptimierung. Schließlich versprechen sie Transparenz, Standardisierung und Effizienz über Abteilungs- und Teamgrenzen hinweg. Doch diese Herangehensweise hat ihren Preis – sie führt zu Kopplung. Und Kopplung ist Gift für jede skalierende Organisation.

Die unsichtbare Gefahr: Organisatorische Kopplung

Ein übergreifender BPMN-Prozess beschreibt oft nicht nur den “Happy Path”, sondern auch detaillierte Entscheidungen und Abläufe, die eigentlich innerhalb einzelner Teams stattfinden sollten. Das Problem: Sobald zentrale Prozesse diese Details festlegen, greifen sie tief in die Arbeitsweise autonomer Teams ein. Das Resultat ist organisatorische Kopplung: Teams sind können innerhalb ihrer Grenzen nicht selbst Veränderungen und Optimierungen vornehmen.

Team Topologies und Fracture Planes: Warum Autonomie zählt

Die Erkenntnisse aus Team Topologies liefern hier wertvolle Impulse. Dort wird beschrieben, dass Software- und Organisationsarchitektur Hand in Hand gehen müssen.

💡 Das Buch zu Team Topologies bietet eine ausführliche Einführung in das Thema. Dort erwarten Dich viele weitere spannende Themen wie Conway’s Law, Team Types und Interaction Modes!

Ein zentrales Konzept dabei: Fracture Planes – natürliche Bruchlinien, entlang derer man ein System sinnvoll aufteilen kann. Dazu zählen z. B. Domänen (Bounded Contexts), Compliance-Anforderungen oder Veränderungen in der Technologie.

Ein übergreifender Prozess, der die interne Logik mehrerer Teams orchestriert, verletzt diese Bruchlinien. Er erzeugt implizite Abhängigkeiten zwischen Teams, die eigentlich entlang dieser Fracture Planes getrennt sein sollten – zum Beispiel entlang von Bounded Contexts in DDD (Domain Driven Design). Die Folge: Fehlende Flexibilität, lange Abstimmungszyklen und eine Organisation, die schlecht auf Veränderungen reagieren kann.

💡 Wer mit Domain Driven Design und dem Konzept des Bounded Contexts noch nicht vertraut ist, bekommt in diesem Video einen kompakten Überblick über das Thema: https://www.youtube.com/watch?v=4rhzdZIDX_k

Conway’s Law und der Irrtum zentraler Orchestrierung

Conway’s Law sagt: „Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.“ Will heißen: Wenn Teams stark gekoppelt arbeiten müssen, spiegeln sich diese Abhängigkeiten früher oder später auch in der Software wider – in Form von Monolithen, komplexer Prozesslogik und fehlender Modularität.

Ein BPMN-Prozess, der Entscheidungen über mehrere Teams hinweg trifft, widerspricht also nicht nur dem Gedanken von Teamautonomie, sondern auch den Prinzipien von skalierbarer, dezentraler Architektur.

Die Lösung: Orchestrierung an den Rändern – nicht im Inneren

Statt übergreifende Prozesse zentral zu orchestrieren, braucht es einen Paradigmenwechsel:

• Keine Einmischung in die interne Orchestrierung von Teams: Jedes Team ist Herr über seine internen Abläufe und Prozesse. Ein übergreifender Prozess darf hier nicht eingreifen.
• Orchestrierung über Schnittstellen, nicht über Details: Wenn eine übergreifende Koordination notwendig ist, dann über explizite Schnittstellen – beispielsweise über Events, APIs oder klar definierte Kontrakte an den Boundaries.
• Choreografie statt Orchestrierung: In vielen Fällen ist eine lose gekoppelter Ansatz über Choreografie der bessere Weg. Hier reagieren Teams auf Events, treffen eigene Entscheidungen und behalten ihre Autonomie. Der Vorteil: Hohe Resilienz, bessere Skalierbarkeit, schnellere Anpassungsfähigkeit.

Beispiel: Order-Fulfillment mit und ohne Kopplung

Schauen wir uns dazu einen vereinfachten Order-Fulfillment-Prozess an. Um das Beispiel greifbarer zu machen, konzentrieren wir uns dabei speziell auf den Bezahlvorgang innerhalb des Gesamtprozesses. Gerade hier zeigt sich besonders deutlich, wie eine zentrale Orchestrierung schnell zu unerwünschter Kopplung zwischen Teams und Domänen führen kann – und wie man dies durch saubere Abgrenzung entlang von Fracture Planes vermeiden kann.

Die Ausgangslage – klassisch übergreifend

Viele Prozessmanager:innen in Organisationen streben übergreifende Abläufe an, die in Prozessen enden, die wie folgt aussehen:

Der Order-Fulfillment-Prozess orchestriert unter anderem direkt den Bezahlvorgang. Das Prozessmodell legt fest, wann und wie bezahlt wird – inklusive aller Fehlerbehandlungen, Rückmeldungen und Eskalationen.

Die ist aus mehreren Gründen problematisch:

• Kopplung an Implementierungsdetails: Der Fulfillment-Prozess kennt Details über Zahlungslogik (z. B. Retry-Strategien, Fraud Checks).
• Verletzung von Team-Grenzen: Änderungen in der Payment-Domäne (z. B. Einführung von Stripe) erfordern Änderungen im zentralen Prozess. Dies wiederum führt dazu, dass teamübergreifende Abstimmungen notwendig werden.
• Geringe Eigenverantwortung: Das Payment-Team kann ihren Prozess nicht selbstständig optimieren oder erweitern.

Diese Form der zentralen Prozesssteuerung ignoriert die natürlichen Fracture Planes zwischen Order und Payment – z. B. unterschiedliche Verantwortlichkeiten, rechtliche Anforderungen, Release-Zyklen, usw.

Die Lösung: Entkopplung über Domänengrenzen

In der entkoppelten Version respektieren wir den Fracture Plan. Der Order-Prozess orchestriert nicht mehr, sondern kommuniziert über klare Schnittstellen:

Was sich verbessert:

• Bounded Contexts werden respektiert: Payment ist eine eigenständige Domäne mit eigener Logik und Verantwortung.
• Teams sind autonom: Das Payment-Team kann unabhängig iterieren, Technologien wechseln oder Abläufe optimieren – solange das Event-Interface stabil bleibt.

Der Order-Prozess kann weiterhin in der Verantwortung eines Teams bleiben – ohne dass dieses Team die fachlichen Details anderer Domänen mitverantworten muss.

Fazit: Prozesse müssen zur Teamstruktur passen – nicht umgekehrt

Übergreifende BPMN-Prozesse sind ein Relikt aus Zeiten zentraler Steuerung und Kontrolle. In modernen, teamzentrierten Organisationen mit klaren Fracture Planes und Bounded Contexts sollten Prozesse entlang der Teamgrenzen geschnitten werden – nicht darüber hinweg.

Die Zukunft gehört leichtgewichtiger Koordination, klaren Schnittstellen und dezentraler Entscheidungsfindung. Nur so entsteht eine Organisation, die wirklich beweglich, skalierbar und anpassungsfähig ist.