Auf dem Laufenden bleiben?
Erhalten Sie immer die neuesten Infos!

BPMN 2.0 am Beispiel: Incident Management

support

Stephen White hat bereits darüber geblogged: BPMN 2.0 ist fertig, vom OMG Architecture Board abgenommen und wird bald offiziell veröffentlicht. Camunda wurde in der Finalization Task Force (FTF) vor allem von Falko Menge vertreten, and er hat dort einen sehr guten Job gemacht (vielen Dank, Falko!). Falko und ich haben auch einen guten Teil des „BPMN 2.0 by Example“-Dokumentes geschrieben (vielen Dank an dieser Stelle an Ivana Trockovitch, Denis Gagné und die weiteren Autoren!), das als Tutorial dienen soll, um die BPMN Grundprinzipien zu verstehen. Weil das ganze Paket noch nicht offiziell veröffentlicht wurde, will ich an dieser Stelle nur eines der beiden Kapitel bloggen, die aus unserer Feder stammen, und von dem ich glaube, dass es besonders interessant ist für jeden, der von „fachlich verständlichen“ Prozessdiagrammen zu „direkt ausführbaren“ Prozessmodellen auf Basis von BPMN 2.0 – XML kommen möchte.

An einigen Stellen habe ich noch Kommentare aus unserer Projektpraxis heraus eingefügt, die natürlich nicht ins offizielle OMG Dokument durften. Für diesen deutschen Blog Post habe ich außerdem die Texte, nicht aber die Abbildungen übersetzt. Wenn Sie auch die Texte im englischen Original lesen möchten, sollten Sie auf „Englisch“ umschalten.

Kapitel 6: Incident Management

In diesem Kapitel wollen wir die verschiedenen Perspektiven zeigen, die man mit Hilfe von BPMN auf denselben Prozess einnehmen kann. Im ersten Schritt zeigen wir ein relativ leicht lesbares Diagramm, das einen Incident Prozess aus einer High Level – Perspektive beschreibt. Später verfeinern wir dieses Modell, indem wir von einer Orchestrierung zur einer Kollaboration bzw. Choreographie übergehen. Im letzten Schritt klären wir anhand der organisatorischen Zusammenarbeit im Prozess, wie eine Process Engine bestimmte Teile des Prozesses durch Aufgabenzuordnung etc. steuern könnte. Der Hauptzweck dieses Kapitels ist es zu zeigen, wie Sie mit BPMN sehr einfache und eher abstrakte Prozessdiagramme erstellen können, aber auch detaillierte Sichten auf die menschliche Zusammenarbeit einnehmen und letztendlich eine Spezifikation für eine technische Umsetzung erstellen können.

Prozessmodelle für Fachabteilungen UND die IT zu erstellen, ist tatsächlich eines unserer absoluten Kernthemen in der Beratung. Und ist es natürlich auch immer eine große Herausforderung. Uns war es wichtig im Beispieldokument zu zeigen, dass BPMN nicht zwangsläufig „zu kompliziert fürs Business“ ist, weil das nämlich absolut davon abhängt, wie Sie tatsächlich bei der Modellierung mit BPMN arbeiten. Darum brauchen wir auch immer ein methodisches Framework auf Basis von BPMN, wenn wir sie in größeren Modellierungsvorhaben anwenden möchten.

6.1 High Level – Modell für den schnellen Überblick

Incident Management level 1

Figure 6.1: Incident management aus einer High-Level-Perspektive


Der hier gezeigte Incident Management Prozess eines Softwareherstellers wird von einem Kunden ausgelöst, der sich mit einem Problem in der Software an seinen Account Manager wendet. Zunächst sollte der Account Manager versuchen, das Problem selbständig zu erkennen und dem Kunden die Lösung zu erklären (z.B. wenn es sich um einen einfachen Bedienfehler handelt). Falls das nicht geht, wird der AM das Problem an einen 1st Level Support Agent übergeben, der es ggf. wiederum an den 2nd level Support Agent weiterreicht. Der 2nd Level Support Agent muss klären wir das Problem gelöst werden kann. Wenn er in dieser Hinsicht unsicher ist, kann er auch einen Entwickler dazu befragen. In jedem Fall wird am Ende der Account Manager dem Kunden den Lösungansatz erklären.
Dieses Diagramm ist sehr einfach und im Grunde ein „Happy Path“, weil wir davon ausgehen dass wir immer eine Lösung finden, die wir dem Kunden erklären können. Dieses Modell enthält überhaupt keine Details der Zusammenarbeit zwischen den beteiligten Angestellten, und die nicht weiter typisierten Aufgaben zeigen, dass wir keinerlei Information darüber haben, ob der Prozess oder Teile davon von einer Process Engine ausgeführt werden können. Dieses Diagramm ist hilfreich um den Prozess abzugrenzen, und um ein Grundverständnis über den Ablauf und die wichtigsten Schritte zu bekommen, aber nicht um in die Details einzusteigen und Verbesserungsmöglichkeiten oder gar Software-Umsetzungen zu diskutieren.

In unserem Framework nennen wir diese Art von Diagrammen „strategische Prozessdiagramme“, oder manchmal auch „logisch-abstrakte Prozessdiagramme“. Man könnte sagen dass diese Art der Prozessmodellierung zur Process Modeling Conformance sub-class „Descriptive“ passt, die in der BPMN 2.0 Spezifikation definiert ist. Wir modellieren auf diese Art sehr häufig bei Ist-Erhebungen und in den frühen Phasen eines Verbesserungsprojekts. Und oft benutzen wir auch gar keine Software-Tools dafür, sondern Whiteboards oder manchmal auch unsere selbstgebastelten BPMN-Magnete.
Die Diagramme in diesem Beispieldokument sind allerdings allesamt mit dem Visio-basierten BPMN Modeler der Firma Trisotech erstellt worden, das von Denis Gangé bereitgestellt wurde. Der Vorteil war nämlich, dass wir mit dem Tool aus den Diagrammen heraus dann auch schon direkt das BPMN 2.0 XML serialisieren konnten 🙂

6.2 Detaillierte Kollaboration und Choreographie

Figure 6.2: Incident Management as detailed collaboration

Figure 6.2: Incident Management als detaillierte Kollaboration

Wir können einen präzisen Blick auf das Ping-Pong-Spiel zwischen Account Manager, Support Agents und Entwicklern werfen, indem wir von einem Single-Pool-Modell zu einem Kollaborationsdiagramm wechseln. Jetzt können wir mehr Details in den Prozessen der Beteiligten erkennen, z.B. den Dialog zwischen Account Manager und Kunde, um das Problem zu klären, oder dass der 2nd Level Support Agent einen Request ins Product Backlog einträgt, wenn das Problem erst mit dem nächsten Release behoben werden kann. Wir haben außerdem jede Aufgabe als „manuell“ typisiert, was bedeutet dass wir den Prozess derzeit immer noch als komplett manuell gesteuert verstehen, also ohne Abbildung in einer Process Engine. Das könnte, hypothetisch gesprochen, der Ist-Zustand des Prozesses sein, bevor wir eine Process Engine einführen. Der nächste Schritt könnte jetzt sein zu entscheiden, ob der komplette Prozess durch eine Process Engine umgesetzt werden soll, oder nur Teile davon. Aber bevor wir dieses Thema diskutieren, können wir noch einen Blick auf eine andere Art der Modellierung des Ping-Pong-Spiels werden, nämlich auf das unten gezeigte Choreographiediagramm.

Figure 6.3: Incident Management as choreography

Figure 6.3: Incident Management als Choreographie

Dieses Diagramm zeigt nur die Aufgaben, die sich der der Kommunikation zwischen den Prozessbeteiligten widmen, und versteckt alle internen Schritte, wie z.B. die Aufgabe, einen neuen Request ins Backlog einzutragen. Beachten Sie dass die Diagramme in 6.1 und 6.2 nicht formal miteinander verknüpft sind, während 6.2 und 6.3 dasselbe semantische Modell besitzen und wirklich nur unterschiedliche Sichten darstellen. Für das serialisierte XML des zugrundeliegenden semantischen Modells, siehe Anhang A.

Einige BPMN-Experten halten Kolloborationsdiagramme, also die Modellierung unterschiedlicher Prozessbeteiligter in jeweils eigenen Pools, nur für sinnvoll, um die Zusammenarbeit unterschiedlicher Unternehmen (B2B) darzustellen. Man kann Kollaborationsdiagramme hierfür verwenden, aber ihr Nutzen beschränkt sich definitiv nicht nur auf dieses Thema. Tatsächlich kann es gerade in NICHT prozessorientierten Unternehmen sehr erhellend sein, die Zusammenarbeit zwischen Abteilungen, Teams oder gar Rollen (wie wir das hier gemacht haben) explizit mit Pools und Nachrichtenflüssen zu modellieren. Und es kann einen ersten Schritt in die Richtung der Anforderungserhebung für eine Workflow-Lösung darstellen, wie im folgenden Abschnitt gezeigt wird.

6.3 Menschliche vs. technische Kontrollflüsse

Figure 6.4: Incident Management with human-driven and system-driven pools

Figure 6.4: Incident Management mit menschlich und technisch gesteuerten Pools

Wenn wir uns vorstellen, dass wir ein Projekt zur Automatisierung des Incident Management Prozesses realisieren, sollten wir jetzt entscheiden, welche Teile des Prozesses tatsächlich in einer Process Engine umgesetzt werden sollen, und welche auch zukünftig von Menschen gesteuert werden. In diesem Szenario haben wir z.B. entschieden, dass der Account Manager nicht mit Web-Formularen oder Aufgabenlisten belästigt werden soll, sondern einfach nur eine Email schickt, um ein Problem zu melden, und eine Email bekommt, wenn die Klärung abgeschlossen ist.

Dasselbe gilt für den Softwareentwickler: Angenommen der 2nd Level Support Agent sitzt im selben Raum wie die Entwickler. Es ist möglicherweise effizienter, wenn der Support Agent einfach rüber zum Entwickler läuft und das Problem bespricht, als ein zeitraubendes Ping-Pong-Spiel mit Aufgabenzuordnungen zu spielen.
Deshalb wollen wir diesen Teil des Prozesses ebenfalls der menschlichen Steuerung überlassen, und die process engine nicht dafür einsetzen, die Zusammenarbeit zwischen 2nd level support und Softwareentwicklern zu steuern. Aber wir wollen die Zuordnung von Tickets zu 1st und 2nd level support agents von einem Trouble Ticket System erledigen lassen, das nun die Rolle der Process Engine einnimt, und deshalb in einem eigenen Pool modelliert wird.

Dieses System kann Emails verarbeiten, die vom Account Manager kommen, und entsprechende Tickets anlegen. Wenn der 1st level support agent entscheidet dass es sich um ein Problem für den 2nd level support handelt, dokumentiert er seine Entscheidung und schließt die zugeordnete Aufgabe „edit 1st level ticket“ ab. Das Trouble Ticket System leitet nun das Ticket an den 2nd Level Support Agent weiter.

Wenn dieser Agent fertig ist, deklariert er evtl., dass das Problem erst im nächsten Software Release behoben wird. In diesem Fall macht das Trouble Ticket System einen Service Call auf das Product Backlog System, ein neues Feature, das wir mit unserer Process Engine eingeführt haben: Der Eintrag muss also nicht mehr manuell gemacht werden. Am Ende schickt das Trouble Ticket System eine Email an den Account Manager, mit dem Ergebnis der Klärung, und schließt das Ticket. Der Account Manager kann dann dem Kunden die Lösung anhand der Informationen aus der Email erklären.

Figure 6.6: This is the only part of the whole collaboration we will execute in a process engine

Figure 6.6: Das ist der einzige Teil der gesamten Kollaboration der in einer Process Engine ausgeführt wird.

Den „menschlichen“ vom „technischen“ Kontrollfluss zu trennen, ist der Kern unseres Modellierungsansatzes, wenn wir Prozessmodelle für Business und IT harmonisieren. Wie können wir konsistent darstellen, dass einige Routing-Entscheidungen, d.h. XOR-, AND- und Event-Gateways, von der Process Engine getroffen werden, und andere von den Menschen, die in den Prozessen arbeiten? Gar nicht, solange wir beide in demselben Pool modellieren! Für einen einzigen Pool kann es auch immer nur eine einzige „Steuerungsmacht“ geben. Deshalb ist es auch völlig egal in welche Lane man ein Gateway legt (eine Tatsache die BPMN-Anfänger i.d.R. nicht wissen und nur schwer nachvollziehen können), denn das Gateway wird sowieso nur von dieser einen einzigen, dem Pool zugeordneten Steuerungsmacht interpretiert. Letztendlich wird nur ein einziger Pool in diesem Diagramm durch die Process Engine tatsächlich ausgeführt, die anderen werden hingegen von den Menschen „ausgeführt“, die in dem Prozess arbeiten (Account Manager, Support Agents, Entwickler). Wir haben auch ein ausführbares BPMN 2.0 XML des Process Engine Pools für das Beispieldokument erstellt.

Figure 6.5: This rather simple diagram is all we have to show to the account manager

Figure 6.5: Dieses relativ einfache Diagramm ist das Einzige, das wir dem Account Manager zeigen


Natürlich ist dieser Ansatz, menschliche und technische Kontrollflüsse in einem Kollaborationsdiagramm zu modellieren, nur ein Vorschlag. Er soll eine Idee geben, wie man Kollaborationsdiagramme sinnvoll verwenden kann. Er soll außerdem zeigen, wie BPMN das Business-IT-Alignment von Prozessmodellen unterstützen kann: Wir können den modellierten Process Engine Pool an eine tatsächliche Process Engine zur Ausführung übergeben, während wir die anderen Pools unseren Prozessbeteiligten ganz isoliert zeigen können, um ihre Beteiligung in der Zusammenarbeit anhand dieser relativ einfachen Prozessdiagramme zu diskutieren, die alle auf demselben, konsistenten Kollaborationsdiagramm basieren. Das verschafft uns die Möglichkeit, sowohl mit den Fachabteilungen, als auch mit der IT über dasselbe Prozessmodell zu sprechen, ohne die Fachabteilungen mit zu komplexen Diagrammen zu überfordern, oder die IT mit zu ungenauen Prozessmodellen zu versorgen.

Weitere Anmerkungen (nicht Teil des Beispieldokumentes)

Im Prinzip funktioniert der ganze Ansatz so:

  • Ein „strategisches“ Prozessdiagramm machen (Figure 6.1), also eine einfache Skizze für den schnellen Überblick
  • Ein „operatives“ Prozessdiagramm machen (6.2), um die Zusammenarbeit zu analysieren.
  • Das Diagramm mit den Aspekten einer Process Engine anreichern, und in diesem Zusammenhang einen Pool für die Process Engine hinzufügen.
  • Diesen Process Engine – Pool in die technische Umgebung übernehmen und für die Ausführung anreichern (ein „technisches“ Prozessdiagramm machen), siehe auch hier und hier.

Defining Views in Signavio

Sichten in Signavio definieren

Um nur einzelne Ausschnitte aus dem „großen“ Kollaborationsdiagramm den einzelnen Zielgruppen zeigen zu können, also z.B. nur den Pool des Account Managers eben nur dem Account Manager zu zeigen, brauchen wir natürlich ein gewisses Tooling: Wir wollen ja keine redundanten Diagramme erzeugen, wo das eine nur einen einzigen Pool enthält, und das andere dann die gesamte Kollaboration. Deshalb haben unsere Freunde bei Signavio ein ziemlich cooles „View-Konzept“ für uns entwickelt, mit dem wir bestimmte Sichten auf ein Kollaborationsdiagramm definieren können, um diese dann den entsprechenden Prozessbeteiligten für die Diskussionen etc. bereitstellen zu können.

Außerdem implementieren wir gerade die gesamte Tool-Kette vom Business zur IT auf Basis von Open Source Komponenten in unserem Projekt camunda fox, insofern lohnt es sich hier am Ball zu bleiben :-).

Schon gelesen?

Scientific performance benchmark of open source BPMN engines

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

Neues Whitepaper: Der Mythos Zero-Coding BPM

7 Kommentare

Hinterlassen Sie eine Antwort