Kollaboration-150x150Was ist BPMN 2.0? Hier finden Sie eine Ultra-Kurz-Einführung in die Methode der Prozessmodellierung. Das Kollaborationsdiagramm in der BPMN (Business Process Model and Notation) ist hervorragend geeignet, komplexe Abhängigkeitsbeziehungen zwischen Prozessen in einer Organisation transparent und verständlich zu machen.
Ich möchte in den nächsten Wochen einige Beispiele aus der Beratungspraxis schildern, wo das Kollaborationsdiagramm als Instrument der Organisationsentwicklung hilfreich ist. Hier ist zunächst die Einführung „BPMN in a nutshell“:

„vorher“ und „nachher“

In der Prozessmodellierung geht es darum, eindeutig und verständlich zu beschreiben, was getan wird. Was ist notwendig, um aus dem Zustand zu Beginn eines Prozesses („vorher“) den Zustand nach dem Prozess („nachher“) zu machen?

Sie kennen sicherlich die tollen Bilder aus der Werbung: Da wird ein trauriges pickeliges Gesicht als „vorher“ gezeigt, das schöne glatte Lächeln als „nachher“. Das „dazwischen“, also die Behandlung mit der Wundercreme, muss man nicht mehr zeigen, der Leser versteht die Botschaft schon, wenn die tolle Tube unter dem Bild abgebildet ist.

Offenes Training zur BPMN und DMN
Sie wollen den Modellier-Standard für digitale Prozesse richtig lernen? Melden Sie sich gleich an zum offenen Training in Nürnberg am 16.-18. Oktober für BPMN. Ein Training zum Geschäftsregelmanagement mit DMN gibt’s gleich anschließend am 19./20. Oktober.

Mehr erfahren – BPMN Training

Mehr erfahren – DMN-Training

In der Prozessmodellierung sind die Zustände „vorher“ und „nachher“ als Start- und End-Ereignisse eines Prozesses bezeichnet. Zum Beispiel das Startereignis (der Zustand vorher) „eine Anfrage ist eingegangen“ und das Endereignis (der Zustand nachher) „die Ware ist geliefert“. Dazwischen passiert der Prozess, den wir beschreiben wollen.

Nun ist eine solche Prozessbeschreibung wenig informativ, wenn sie nur aus einem „vorher“ und „nachher“ besteht. Dennoch können wir daran schon eine wichtige Unterscheidung festmachen. Das Startereignis (dünner Kreis) tritt in der Umwelt des Prozesses ein, das Endereignis (dicker Kreis) wird vom Prozess selber hergestellt. Wir nennen das eine das eingetretene Ereignis, das andere das ausgelöste Ereignis. Aber zwischen Start- und Endereignis passiert ja noch was.

Meilensteine und Wartepunkte

Wir können die Zustände die zwischendurch eintreten, als Zwischenereignisse beschreiben. Das sind die Meilensteine, die einen wichtigen Zustand markieren. In unserem Fall der Moment, wo der Lieferant nach der eingegangenen Anfrage ein Angebot versendet hat. Das ist ein ausgelöstes Ereignis, wenn wir den Prozess aus der Sicht des Lieferanten beschreiben. Denn der Lieferant erstellt ja dieses Angebot.

Anders ist das mit dem Auftrag – den bekommt der Lieferant ja von seinem Kunden. Auf den Eingang des Auftrags hat er keinen Einfluss – es ist also ein eingetretenes Zwischenereignis. Und wenn Ereignisse mit Nachrichten verbunden sind, markieren wir sie mit einem Nachrichtensymbol. Es gibt also eingetretene und ausgelöste Nachrichtenereignisse, das ausgelöste ist an dem schwarzen Briefumschlag, das eingetretene an dem weißen Briefumschlag zu erkennen.

Ein eingetretenes Zwischenereignis symbolisiert im Prozess einen Punkt, wo der Prozess auf eine Reaktion aus seiner Umwelt wartet.

Aber schließlich geht es in einer Prozessbeschreibung ja darum, was im Prozess getan wird. Wir stellen alle Aufgaben des Prozesses als Rechtecke dar und schreiben hinein, was der Verantwortliche da gerade tut. Dieser Part des Prozessmodelles ist wirklich simpel.

Ein wichtiges Element in der Darstellung von Prozessen sind Entscheidungen. Damit fassen wir die Logik „wenn … dann“ in unserem Prozessmodell. Die BPMN kennt zwei unterschiedliche Entscheidungen: die im Prozess selbst getroffene Entscheidung und die in der Umwelt gegebene Entscheidung. Wenn der Lieferant entscheidet, ob er überhaupt ein Angebot abgeben will, trifft er die Entscheidung selbst.

aktiv entscheiden oder auf Umwelt reagieren

Wir modellieren eine Aktivität „Anfrage bewerten“ und haben danach die Information im Prozess, ob der Lieferant ein Angebot abgeben will oder nicht. Den unterschiedlichen Ablauf zeigen wir mit einer Verzweigung im Prozess. Da die Information „Anfrage interessant? Ja oder nein“ ja bereits vorliegt, nennen wir die Verzweigung „datenbasiertes Gateway“. Das erkennen wir an dem „x“ in dem Raute-Symbol. Je nachdem, welcher Pfad des Prozesses gewählt ist, erreicht der Prozess ein anderes Endereignis.

Anders die Entscheidungen aus der Umwelt, auf die ein Prozess reagieren muss: Da weiß man zum Zeitpunkt der Verzweigung noch nicht, wo es weitergehen soll. Wenn der Auftrag kommt, soll geliefert werden, wenn der Auftrag nicht kommt, kann man das Angebot zu den Akten legen. Der Ausgang der Verzweigung hängt also von eingetretenen Ereignissen ab.

Darum nennen wir die Verzweigung „ereignisbasiertes Gateway“, wir erkennen es an dem Fünfeck in der Raute. Aber wie stellen wir ein Ereignis dar, das gar nicht eintritt – eben den nicht gekommenen Auftrag? Wir nutzen dazu ein Zeitereignis und stellen damit einen Fristablauf dar. So ein Angebot ist ja nur für eine begrenzte Zeit gültig. Nach dem ereignisbasierten Gateway stehen also zwei Ereignisse und danach folgend die Abläufe, die bei Eintreffen dieser Ereignisse folgen. Das erste Ereignis, das eintrifft, ruft seine folgenden Elemente auf, das andere Ereignis wird nicht mehr aktiviert.

Es gibt noch zahlreiche weitere Elemente in der Modellierungssprache, aber diese wenigen Elemente genügen, um die grundlegende Bedeutung der Darstellung zu verstehen. Das Prozessdiagramm zeigt, was aus der Sicht eines Prozesses passiert, wenn das Startereignis eintritt.

Kollaboration zeigt komplexe Abhängigkeiten

Solche Diagramme zur Darstellung einfacher Abläufe sind ja schön und gut – aber das Leben ist doch viel komplexer. Meistens habe ich doch gar nicht den Einfluss auf alle Prozessbeteiligten und muss trotzdem schauen, wie ich ans Ziel komme. Aus diesem Grund nutzen wir in der BPMN-Modellierung das Instrument der Kollaboration. Damit zeigen wir die Abhängigkeiten und Kommunikationen zwischen Prozessen, die unter verschiedenen Verantwortungen laufen. Das kommt schon recht nahe an die Realität. Der Lieferant aus unserem Beispiel kann seinen Ablauf selbst bestimmen, aber er hat keinen Einfluss auf den Ablauf beim Kunden. Dennoch hängt sein Prozess maßgeblich von dem seines Kunden ab.

Das Kollaborationsdiagramm zeigt die beiden Prozesse von Lieferant und Kunden und macht mit der Darstellung von (gestrichelten) Nachrichtenflüssen deutlich, wann ein Prozess mit dem anderen kommuniziert und wann ein Prozess von einem anderen abhängt – also auf eine Nachricht wartet. Wenn wir in unserem Beispiel darstellen, dass der Kunde unser Angebot erhält und darauf reagiert, wird deutlich, wo zwischen den beiden Prozessen die Übergaben und Abhängigkeiten bestehen.

Dazu zeichnen wir um den Prozess, der in der Verantwortung einer Organisation liegt, einen Kasten – das heißt im BPMN-Vokabular ein „Pool“. Prozesse, die in einem anderen Verantwortungsbereich liegen, werden in einem anderen „Pool“ dargestellt. Die Sequenzfolgen, die wir als Pfeile im Diagramm kennengelernt haben, können nur innerhalb eines Pools fließen. Denn die Abfolge der Aktivitäten liegt ja bei jedem Pool in einer eigenen Verantwortlichkeit. Zwischen den Pools gibt es nur eine Nachrichtenkommunikation. Ich finde, mit dieser Konvention trifft die BPMN in der Realität der Unternehmen den Nagel auf den Kopf.

Realistische Darstellung

Andere Modellierungssprachen stellen die Aktivitäten von Kunde und Lieferant als selbstverständliche Abfolge in einer Sequenz dar – so als würden sie von einer magischen Hand koordiniert. Wir wissen aber, dass das nicht so ist. Und wer sich in seinem Unternehmen umschaut, wird schnell merken, dass das auch für verschiedene Abteilungen in einem Unternehmen nicht gilt. Ein Kollaborationsdiagramm, das die Kommunikation zwischen den Prozessen in einem Unternehmen zeigt, ist also eine ehrlichere Darstellung als die glatte Sequenz.

Das Kollaborationsdiagramm ist ein hervorragendes Instrument, komplexe Zusammenhänge in einer Organisation verständlich transparent zu machen. Jeder Verantwortliche kann den Ablauf aus seiner Sicht schildern – im Kollaborationsdiagramm zeigt sich, ob die Prozesse sauber miteinander verwoben sind. Oft sind sie es nicht. Das spüren zwar alle Beteiligten schon, mit diesem Instrument können sie aber die Fehlerquelle genau festmachen und Lösungsszenarien bewerten.

Bevor man also mit Umstrukturierung oder einer Software-Einführung die Organisation verändert, macht es Sinn, den aktuellen Stand der Abläufe in einem Kollaborationsdiagramm festzuhalten und den zukünftig geplanten Ablauf in einem zweiten Diagramm daneben zu stellen. Jetzt wird jedem klar, was sich in Zukunft ändern wird. Widerstand gegen Veränderung kann frühzeitig auf den Tisch kommen.

In der IT-Beratung gehen wir noch einen Schritt weiter: Wir verstehen nicht nur Organisationseinheiten als Pool im Kollaborationsdiagramm, sondern auch die verwendeten Applikationen. So wird deutlich, Wer wann welche Applikation nutzt und wie die Systeme untereinander kommunizieren müssen. Diese Sicht ist ausgesprochen hilfreich, organisatorische Abläufe und die Architekturen von Applikationen in einen Überblick zu bekommen.

Tagged on:

Schreibe einen Kommentar

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