Hierarchische Prozessmodelle über das gesamte Unternehmen sind theoretischer Ballast für BPM-Projekte. Sie verursachen enormen Pflege-Aufwand und sind entweder unvollständig oder unübersichtlich. Hier zeige ich auf, dass man darauf gut verzichten kann.

Hierarchische Ebenenmodelle sind out

In BPM Projekten begegne ich immer wieder sogenannten Ebenen-Modellen für Unternehmensprozesse. In einer „Ebene 1“ gibt es eine Prozesslandkarte, die alle Kernprozesse, Führungsprozesse und Unterstützungsprozesse in dicken Blockpfeilen symbolisieren. In einer „Ebene 2“ jeder dieser Blockpfeile wieder in einem ähnlichen Diagramm aufgeschlüsselt und listet die einzelnen im Alltag sichtbaren Prozesse als Blockpfeil auf. Die „Ebene 3“ schließlich zeigt eben diese „echten“ Prozesse in einem detaillierten Prozessdiagramm. So hat man es vor Jahren gelehrt, als ARIS und ähnliche Modellierungskonzepte den Markt beherrschten. Heute wird immer öfter die BPMN 2.0 als Modellierungssprache verwendet, aber das eindimensionale hierarchische Ebenenkonzept bleibt davon unberührt: Man verwendet einfach auf Ebene 3 die BPMN statt der alten EPK-Modelle. Das klappt so aber nicht.

Ein Prozess – verschiedene Perspektiven

In einem BPMN Kollaborationsdiagramm werden die Aktivitäten in mehreren Organisationseinheiten als unterschiedliche „Pools“ dargestellt. In jedem Pool gibt es einen eigenen Start und ein Ende des Prozesses. Das Diagramm versteht daher die verschiedenen Pools als eigene Prozesse, deren Zusammenwirken hier dargestellt wird. Daher der Name „Kollaborationsdiagramm“. Und wenn in einem Diagramm mehrere Prozesse gezeigt werden – wie soll dieses Diagramm dann in einer hierarchischen Zuordnung genau einem übergelagerten Prozess zugeordnet werden?

Häufig nutzen Modellierer auch den „geschlossenen Pool“ um Interaktionen mit Prozessen darzustellen, die im Diagramm gar nicht näher betrachtet werden sollen. Man modelliert einfach einen Nachrichtenfluss an einen Pool und drückt damit aus: „In dem anderen Prozess passiert dann etwas, das ich hier nicht näher darstelle.“ Unter Umständen kommt später im Prozess ein Nachrichtenfluss zurück, auf den im dargestellten Prozess gewartet wird. So wird die Kollaboration deutlich, ohne dass die Details des anderen Prozesses bekannt sein müssen.

Eindimensionale Hierarchie greift zu kurz

Später wird man vielleicht diesen hier „geschlossen“ dargestellten Pool in einem eigenen Modell darstellen (und umgekehrt den anderen Prozess als geschlossenen Pool nur andeuten). Dann gibt es mehrere Prozessdiagramme, die sich auf den gleichen Prozesszusammenhang beziehen. Da greift eine eindimensionale Hierarchie zu kurz.

In der Praxis beschreibt man häufig ein „operatives Modell,“ das die Zusammenarbeit zwischen den verschiedenen Organisationseinheiten oder mehreren Unternehmen, Kunden und Lieferanten beschreibt. Die dabei verwendeten IT-Systeme, die Daten liefern und verarbeiten, sind einfach geschlossene Pools. Diese Diagramme haben die organisatorischen Zusammenhänge im Fokus und blenden die technischen Details aus.

technische Pools

Will man aber die Abläufe mit einer automatischen Weiterleitung durch ein Workflow-Tool unterstützen, braucht man die technischen Zusammenhänge – man zeichnet ein „technisches Modell“, wo alle Module und Systeme ihren Pool bekommen und die organisatorischen Einheiten als geschlossene Pools marginal sind.

Befolgt man außerdem noch den wichtigen Rat, sich über jeden Zusammenhang zunächst in einem „beschreibenden Modell“ einen groben Überblick zu verschaffen, dann kommt noch ein drittes Modell hinzu, das nicht mehr in die Hierarchie passt. Will man trotzdem die 1-zu-1 Zuordnung aus einem hierarchischen Ebenenmodell einhalten, wird die Ebene 2 überbordend komplex. Ihr Zweck, eine Orientierung zu geben, geht verloren.

Prozesse in Verzeichnis ablegen

Mein Tipp: Belassen Sie es bei einer Prozesslandkarte („Ebene 1“). Das hilft, sich in den Prozessmodellen zurechtzufinden und beschreibt das Unternehmen in einem Bild. Verzichten Sie darauf, dass weitere Modelle von hier aus angeklickt werden können. Statt dessen nutzen Sie ein klassisches Verzeichnis (zum Beispiel in einer Sharepoint-Liste), um die weiteren Modelle zu ordnen. Unterscheiden Sie schon bei der Benamung der Modelle in beschreibende, operative und technische Modelle und pflegen Sie die weitere Ordnung der Modelle über die Attribute der Liste. Das hilft im Alltag, dass jeder schnell das Modell findet, das ihm weiterhilft und befreit Sie vom theoretischen Überbau der Hierarchie-Konzepte.

Welche Erfahrung machen Sie mit solchen Prozess-Hierarchien – Ballast oder Benefit? Ich freue mich auf Ihre Kommentare.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.