Meine Themen: Anforderungen, Anwendungslandschaften und Architekturen.

Seit einigen Jahren dominiert BPMN (Business Model and Notation) die Welt der grafischen Geschäftsprozessmodellierung. Wenn Sie jetzt denken „Brauche ich BPMN unbedingt?“, kann ich Sie beruhigen. Wahrscheinlich werden Sie es nicht unbedingt brauchen. „Aber es spricht wohl nichts dagegen, wenn ich jetzt auch auf den Zug aufspringe?“ Oh doch, Sie könnten eine harte Landung hinlegen! „Also Finger weg von BPMN?“ Keineswegs. Sich mit Geschäftsprozessen zu beschäftigen ist sinnvoll und BPMN kann Ihnen dabei gute Dienste leisten.

Wir setzen in einigen Projekten BPMN ein und schulen unsere Kunden darin. Dabei haben wir bemerkt, dass sich manche BPMN-Neulinge gar nicht darüber im Klaren sind, was sie eigentlich bezwecken. Hier drei typische Anwendungsfälle:

Prozessautomatisierung. BPMN wurde entwickelt, um Geschäftsprozesse ausführbar zu machen. Die Notation bringt alle dazu nötigen Ausdrucksmittel mit. Will man diese Mittel nutzen, hat BPMN die Komplexität einer Programmiersprache und man taucht in eine Welt voller Asynchronität, Nebenläufigkeit und Ausnahmebehandlung ein. Die meisten unserer Kunden brauchen BPMN nicht auf diesem Detailniveau.

Prozessmanagement. Wenn man mit BPMN Prozesse „programmieren“ kann, dann lassen sich damit auch Prozessdurchläufe simulieren, messen und optimieren. Verbal ist es zwar nur ein kleiner Schritt vom Business Process Modeling zum Business Process Management, in der Praxis bedeutet das aber mitunter, ein Unternehmen ganz anders zu organisieren. Unsere Kunden haben meist etwas anderes im Sinn, wenn sie über BPMN nachdenken.

Anforderungsermittlung. Wenn man Software entwickelt oder einkauft, sollten die zu unterstützenden Geschäftsprozesse eigentlich eine zentrale Rolle spielen. Betrachtet man einen typischen Anforderungskatalog für eine Softwareauswahl oder ein Backlog voller User Stories, kann man die Geschäftsprozesse aber kaum erkennen. Zwischen Geschäftsprozessen und Anforderungen klafft eine Lücke. Richtig eingesetzt kann BPMN zum Beispiel einem Product Owner helfen, in Abstimmung mit den Entwicklern fachlich und technisch stimmige Prozesse zu entwerfen und auf User Stories herunterzubrechen.

Richtig eingesetzt?“ Ja, denn BPMN ist nur (oder nicht mal?) die halbe Miete:

  • Sie müssen den Zweck und das inhaltliche Niveau eines Modells im Blick behalten
  • Sie müssen auf einem schmalen Grat balancieren – zwischen notwendigem Abspecken der Notation und dem Verlust von Ausdrucksmächtigkeit und Standardisierung.
  • Sie müssen sich ein Modellierungsvorgehen zurechtlegen. Wie kommen Sie zu Informationen? Wie holen Sie Feedback ein?
  • Sie müssen das Missverständnis Modellierungswerkzeug vermeiden.
"Georgia" by The Library of Congress. Lizenzfrei.

Einer führt den Stift, die anderen nicken stumm. Und wie modellieren Sie?

Ich schrieb eingangs, dass es nicht unbedingt BPMN sein muss. Geht es in erster Linie darum, Fachsprache (im Domain Driven Design: ubiquitous language) zu lernen, kommen Methoden wie Domain Storytelling und Event Storming in Frage. Damit lassen sich ebenfalls Geschäftsprozesse darstellen, allerdings stehen dabei die handelnden Akteure, Arbeitsgegenstände und Ereignisse im Mittelpunkt – also die Grundpfeiler der Domäne. Für uns stellen diese Methoden in erster Linie „Kommunikationswerkzeuge“ dar. Das trifft, entsprechende Schulungen vorausgesetzt, zwar auch auf BPMN zu, aber auf Grund der stärkeren Formalisierung hat sich bei uns der Ausdruck „BPMN als Denkwerkzeug“ eingebürgert. Der vielleicht größte Wert von BPMN liegt für uns nämlich darin, beim Modellieren über Reihenfolgen, Alternativen und Zuständigkeiten nachzudenken.

Jetzt verstehen Sie vielleicht, warum sie auf den BPMN-Zug nicht aufspringen, sondern besser am nächsten Bahnhof einsteigen sollten. Dann kann Ihnen BPMN gute Dienste leisten.