Die Möglichkeiten und Stärken von BPMN (Business Process Model and Notation)
BPMN steht für «Business Process Model and Notation» und ist heute der De-facto-Standard für die Beschreibung von Geschäftsprozessen. Lesen Sie in diesem Beitrag, wie Sie mit BPMN Prozesse zielgruppengerecht, klar und präzise darstellen können.
BPMN steht für «Business Process Model and Notation» und ist heute der De-facto-Standard für die Beschreibung von Geschäftsprozessen. Es heisst, BPMN schliesse die Brücke zwischen Fach und IT, sei aber für den Fachanwender zu kompliziert. Kann ich nun ein BPMN-Tool für meine fachliche Prozessmodellierung verwenden und dann meine Prozesse einfach per Knopfdruck automatisieren?
Gepaart mit Praxistipps gebe ich in diesem Beitrag Antwort auf diese Frage – damit der Einsatz von BPMN 2.0 für Sie ein Erfolg wird.
Erfahrungen prägen BPMN
BPMN wurde ab 2002 ursprünglich vom Konsortium «BPMI.org» entwickelt und ist damit eine relativ junge Notation. Man hatte also bereits zu Beginn einen reichen Erfahrungsschatz mit anderen Notationen gesammelt und konnte so für die neue Modelliersprache auf die Stärken der Vorgänger bauen und gleichzeitig deren Schwächen vermeiden.
Was sind die Besonderheiten von BPMN?
Ereignisse
Ein besonderes Merkmal der Ereignisgesteuerten Prozesskette (EPK) von August-Wilhelm Scheer, bekannt geworden durch das Tool ARIS, sind die Ereignisse. Der Zustand zwischen zwei Aufgaben (Funktionen) wird durch ein Ereignis dargestellt, das einerseits dem Umfeld des Prozesses diesen Zustand mitteilen kann, aber andererseits auch ein Vorkommnis ausserhalb des Prozesses einfliessen lassen kann. So ist ein Ereignis ein sehr mächtiges Element, um einen Prozess mit dessen Umwelt zu synchronisieren.
Mit BPMN werden Ereignisse als Kreis dargestellt, je nach Ausprägung mit einem einfachen, doppelten, gestrichelten oder fetten Rand sowie optional mit einem von 12 Symbolen, um die Art des Ereignisses zu beschreiben. Hier zur Veranschaulichung ein paar wenige Beispiele:
Anders als bei der EPK besteht in BPMN keine Pflicht, nach jedem Arbeitsschritt ein Ereignis einzufügen; es ist einfach eine Möglichkeit, diese gezielt einzusetzen.
Symbolsprache
BPMN bedient sich grundsätzlich der Symbole von ganz einfachen Flussdiagrammen:
- Kreis für Ereignisse
- Raute für Verzweigungen
- (Abgerundetes) Rechteck für Aktivitäten
- Pfeile für den Sequenzfluss (Reihenfolge)
Diese Symbole sind heutzutage in der Regel allen Mitarbeitern geläufig. Zur Präzisierung von Sachverhalten gibt es die Möglichkeit, die Grundsymbole mit Hilfe von kleinen Bildchen (Icons) zu ergänzen. Form und grundlegende Bedeutung bleiben aber dieselbe. Dies senkt die Einstiegshürde für die Leser der Prozessdiagramme und erhöht die Akzeptanz vor allem bei den Fachmitarbeitern.
Vollständigkeit
In früheren Prozessnotationen war es oftmals schwierig, Ausnahmesituationen darzustellen, wie zum Beispiel, dass ein Kunde nicht auf eine zugestellte Offerte reagiert, also weder explizit zu- noch absagt. In der «klassischen» Prozessmodellierung wurden solche Fälle entweder als nicht modellierwürdige, seltene Ausnahmefälle weggelassen oder deren Behandlung wurde in Textform in Anmerkungen zum Modell festgehalten.
BPMN bietet elegante Mittel, um diese Fälle visuell nachvollziehbar und vor allem vollständig abzubilden. Das folgende Bild beschreibt die Situation, in der ein Kunde sich während 30 Tagen nicht meldet und ein Sachbearbeiter wissen muss, wie er mit der Situation umzugehen hat.
Behandlung von Ausnahmen
Der oben beschriebene Sachverhalt ist genau genommen eine Ausnahmebehandlung (Exception Handling), der Umgang mit einer Situation, die man nicht erwartet, die jedoch auch auftreten kann und nicht einfach ignoriert werden darf.
Klare Prozesse mit BPMN 2.0Lernen Sie in unserem Kurs, Geschäftsprozesse zielgruppengerecht, klar und präzise darzustellen. |
Lernen Sie in unserem Kurs, Geschäftsprozesse zielgruppengerecht, klar und präzise darzustellen.
BPMN bietet für die Ausnahmebehandlung (vor allem fachlichen Kontext) eine gut lesbare Möglichkeit mit den sogenannten angehefteten Zwischenereignissen. Diese zeigen an, wie mit einem Ereignis umgegangen werden muss, falls dieses während der Ausführung einer Aktivität auftritt. Das folgende Diagramm zeigt ein einfaches Beispiel.
Eine weitere Darstellung, die eher für ein übergreifendes Exception Handling gilt, wie es in der technischen Umsetzung benötigt wird, ist der «Event Subprocess», auf den ich hier aber nicht weiter eingehe.
Prozess-Interaktion
Eine ganz besondere, aber sehr realitätsbezogene und nützliche Sicht nimmt BPMN in Bezug auf den zu modellierenden Bereich ein. BPMN-Modelle müssen sich nicht auf die «geschlossene» Welt eines einzelnen Prozesses beziehen. Wie bereits im vorherigen Beispiel ersichtlich, kann ein Diagramm mehrere miteinander kommunizierende Prozesse darstellen. Die gestrichelten Pfeile stellen den Nachrichten-Austausch zwischen Prozessen dar und zeigen somit die Schnittstellen der Prozesse auf. Im obigen Beispiel ist ein sehr häufiger Fall gezeigt, bei dem der Fokus auf einem Prozess liegt, dieser aber Nachrichten mit einem anderen Prozess austauscht, dessen interne Funktionsweise uns unbekannt ist. Der Fall, in dem wir die Details mehrerer dargestellter Prozesse kennen, ist im folgenden Beispiel abgebildet.
Tauglich für Fach und Informatik
In der Vergangenheit gab es einen deutlichen Graben zwischen der Beschreibung von Abläufen aus fachlicher Sichtweise und der Spezifikation der diese Abläufe unterstützenden IT-Systeme. Die Problematik ist, dass ein fachliches Modell für einen nicht IT-versierten Fachvertreter lesbar sein muss, für die Umsetzung in einem IT-System aber Präzision und Vollständigkeit, inkl. technischer Details wichtig sind.
Validierung
Die eindeutige Definition von BPMN legt klar fest, was richtig und was falsch modelliert ist. Daher ist es auch möglich, in einem Modellierungssystem Validierungsregeln umzusetzen. Jetzt kann man sich fragen, ob dies nicht eine unnötige Einschränkung ist, die von den Benutzern als Zwängerei empfunden wird. Die klaren Regeln haben aber zwei wichtige Vorteile. Einerseits sind die Regeln natürlich Voraussetzung, um die modellierten Prozesse automatisieren zu können. Missverständnissen zwischen Fach und IT (und Maschine) wird so vorgebeugt. Andererseits helfen die strikten Regeln zu vermeiden, dass die verschiedenen (fachlichen) Modellierer implizites Wissen in ihre Modelle einbauen. Die fachliche Darstellung von Prozessen wird einheitlicher und ist weniger von den Vorlieben der beteiligten Modellierer abhängig, was wiederum die Lesbarkeit erhöht.
Automatisierung und ausführbare BPMN
Inzwischen sind vielfältige Prozessengines verfügbar, die mit BPMN spezifizierte Prozesse ausführen können. Diese Durchgängigkeit erlaubt es natürlich auch, vom ausführenden System Leistungsdaten zurückzumelden, die im BPMN-Modell den relevanten Objekten zugeordnet werden.
Es ist wohl nicht so einfach, wie gewisse Tool-Hersteller dies auf Hochglanzfolien gerne darstellen. Ein aus Fachoptik modellierter Geschäftsprozess ist in der Regel nicht direkt ausführbar, sondern muss erst noch mit IT-Details angereichert werden. Aber BPMN bietet erstmals die Möglichkeit, dass Fach und IT auf derselben Modellbasis und in einer gemeinsamen Notation arbeiten. Dies eliminiert einige Hürden in der Kommunikation zwischen Fach und IT.
Roundtrip Modeling
Eine der grossen Erwartungen an BPMN war von Anfang an die Möglichkeit, Modelle zwischen verschiedenen Tools – sowohl für die Modellierung wie auch für die Ausführung – austauschen zu können. Es hat einige Zeit gedauert und man musste auf BPMN 2.0 warten, bis dies endlich Realität wurde. Im Jahr 2013 haben 8 Tool-Hersteller mit OMG den Praxisbeweis erbracht und ein BPMN-Modell über verschiedene Plattformen weiter- und auch wieder zurückgereicht. Das folgende Bild von OMG zeigt den Testablauf.
Bemerkenswert ist, dass diese zusätzlichen Informationen, mit denen ein fachliches Modellierungs-Tool unter Umständen gar nichts anfangen kann, trotzdem zurückgegeben und erhalten werden kann. Jede Stufe kann das Modell also um Informationen anreichern, die für die anderen Ebenen aber nicht zwingend relevant sein müssen.
Es ist wichtig, dass man in einem Roundtrip-Szenario klare Governance-Regeln festlegt, um die Zusammenarbeit und die Verantwortlichkeiten zu klären. Wenn man zum Beispiel gewährleisten möchte, dass ein Fachvertreter Verantwortung für einen Geschäftsprozess übernimmt, darf ein IT-Mitarbeiter lediglich technische Details ergänzen, nicht aber den fachlichen Inhalt des Prozesses verändern. Ansonsten wird der Fachvertreter die Verantwortung ablehnen!
Tipps für die Praxis
In diesem Überblick habe ich versucht aufzuzeigen, welche Möglichkeiten uns BPMN 2.0 heute bietet. Die Vielfalt der Möglichkeiten darf aber nicht darüber hinwegtäuschen, dass ein Einsatz von BPMN überlegt geplant werden muss. Ich treffe immer wieder Situation an, dass einfach ein paar Tools beschafft werden, in der Meinung, der Standard regle alles und man müsse sich über den konkreten Einsatz in der eigenen Organisation keine Gedanken machen. Dies ist eine falsche Annahme!
Vor einem Einsatz von BPMN (und der dazugehörenden Tool-Beschaffung) müssen die Zielsetzung und das Einsatzszenario klar definiert werden:
- Was wollen wir modellieren?
- Wer ist/sind die Zielgruppe(n) unserer Modelle?
- Welche Bedürfnisse und Fähigkeiten haben die Zielgruppen?
- Mit welchen Bereichen und Tools sollen die Modelle ausgetauscht werden?
- Ist eine Automatisierung angedacht?
Diese und viele weitere Fragen müssen zu Beginn diskutiert werden. Ansonsten riskiert man eine schier endlose Iteration von Anpassungen und Überarbeitungen, die letztlich die Akzeptanz der eigenen Arbeit in der Organisation schwächen.