Ziel vor Augen: Kommunkationsgrundlage schaffen

Wenn wir Prozessmodelle erstellen, müssen wir uns vorher fragen, warum wir das überhaupt tun wollen. Es gibt natürlich viele gute Gründe, aber gerade deswegen muss jeder für sein Projekt die Fragen stellen: Wer soll später mit dem Modell arbeiten? Welche Informationen sollen diese Personen aus den Modellen ziehen? Was soll mit den Modellen passieren?

Die Business Process Model and Notation ist ein ISO-Standard zu Prozessmodellierung (ISO/IEC 19510:2013). Unabhängig von Ihrem konkreten Einsatzziel hat die BPMN 2.0 das grundlegende Ziel eine Kommunikationsgrundlage zu schaffen. Gleich der zweite Satz in der Spezifikation liefert diese wichtige Vorgabe, die auch enthält, für wen die BPMN eigentlich gedacht ist:

„The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.“ (vgl. OMG 2013)

Kurz zusammengefasst: Die BPMN 2.0 bietet eine Kommunikatonsgrundlage für alle Beteiligten, für die Fachabteilung, für die IT und für das Management. Ich betone das in meinen Schulungen unentwegt. Das, was wir modellieren, modellieren wir nie zum Selbstzweck, sondern irgendjemand soll sich das später einmal anschauen und Nutzen daraus ziehen. Und zwar ohne dabei Augenschmerzen zu bekommen. Um das möglich zu machen, müssen wir uns schon vor der ersten Modellierung einige Gedanken machen.

Wir können und wollen in einem Prozessmodell nie alle Details eines Prozesses abbilden. Es handelt sich schließlich nur um ein Modell und bei allen Modellen wird von irrelevanten Details abstrahiert. Wir müssen also festlegen: Was ist relevant? Relevant ist, was mit den Modellierungszielen in einem hinreichenden Zusammenhang steht. Mögliche Ziele habe ich im Folgenden in drei Gruppen eingeteilt:

1. Fachliche Dokumentation

Einige sinnvolle Gründe, Prozessmodelle zur fachlichen Dokumentation zu nutzen und anschließend als „Prozesshandbuch“ bereitzustellen sind:

  • Zur Schulung und Wissenserhaltung im Unternehmen als prozessbasiertes Informationsmanagement.
  • Qualitätsmanagement. Die ISO-9001:2015 fordert explizit die Betrachtung und Dokumentation von Prozessen.
  • Projektbegleitend im Change Management. Jedes Projekt verändert Prozesse!
  • Interne Schnittstellen klären, z.B. Prozesse zwischen verschiedenen Abteilungen
  • Externe Schnittstellen mit Partnern klären, z.B. Kunden oder Lieferanten
  • Compliance nach BDSG und EU-DSGVO sicherstellen

Vielleicht haben Sie Ihre Ziele hier ja schon wieder gefunden. Es gibt aber noch Ziele ganz anderer Art, die ebenso als Treiber bei der Modellierung von Prozessen dienen können.

2. Prozessanalyse

Ein strategisch ausgerichtetes Ziel bei der Modellierung von Prozessen ist die Analyse und kontinuierliche Verbesserung von Prozessen. Meist ist ein „Prozesshandbuch“ hier nicht mehr das geeignete Medium, wir analysieren die BPMN-Prozesse lieber direkt in einer Software mit entsprechenden Funktionen. Dabei wollen wir:

  • Anforderungsanalysen erstellen, z.B. für neue IT-Systeme
  • Prozesskostenrechnung mit variablen und fixen Kosten durchführen
  • Risiken und Schwachstellen im Prozess identifizieren
  • Kennzahlen wie Effizienz, Kosten, Laufzeiten und Ressourcenbedarf analysieren
  • Kennzahlen verbessern, z.B. Effizienzsteigerung

3. Technische Steuerung

Ein ganz anderer Fokus ist die automatisierte Steuerung von Prozessen mit Hilfe eines Workflow-Management-Systems In BPMN 2.0 modellierte Prozesse können von einem Workflow-Management-Systems gesteuert, teilweise automatisiert und überwacht werden können. Unsere Motivation dabei dürfte sein:

  • Aufgaben- und Informationsfluss steuern: Die richtige Person erhält zur richtigen Zeit die richtigen Informationen
  • Orchestrierung der Nutzung unterschiedlicher IT-Systeme
  • Automatisierung von Aufgaben
  • Ticketsystem im Prozessportal für die Mitarbeiterinnen und Mitarbeiter (und ggf. Kunden)
  • Monitoring von Prozesskennzahlen
  • Überwachung von kritischen Prozessen

Die Steuerung von Workflows per BPMN zu lösen, bringt Transparenz in ihre Geschäftslogik. Die Fachabteilungen können den Prozess selbst in der BPMN 2.0 entwerfen. Ihre Anwendungen sind dann keine Black-Box mehr, die nur von der IT durchschaut werden.

Das eine solche Automatisierung mit der BPMN 2.0 möglich ist, ist herauszuheben, wenn man bedenkt, dass man dafür früher Zwischenschritte z.B. über BPEL brauchte, um vorhandene Prozessdiagramme in einem Workflow-System ausführbar zu machen. Man merkt der Notation diese technische Möglichkeiten aber stark an. Einige der Elemente der BPMN 2.0 werden primär für die Prozessauatomatisierung benötigt und schrecken andere Anwender ab.

Modellierungskonventionen bilden

Wir müssen für jedes Projekt, für jedes Modellierungsvorhaben und ggf. für das unternehmensweite Prozessmanagement entscheiden: Was sind die Ziele? Ein Modell ist immer nur so gut, wie die Vorgaben, die wir an seinen Zweck stellen.

Wenn wir den Modellierungszweck festgelegt haben, bietet uns das schon viel Orientierung bei den folgenden Fragen: Welche Detailtiefe brauchen wir in unseren Modellen? Welche Aspekte müssen wir abbilden, wovon können wir abstrahieren? Was können wir voraussetzen, was ist irrelevant für unseren Zweck? Welche Elemente der BPMN 2.0 verwenden wir in unseren Modellen?

Ich empfehle immer, diese Fragen in einem kurzem Dokument „Modellierungskonventionen“ zu beantworten. Es liest sich wie ein Handbuch für den Schnelleinstieg in Ihre Prozessmodelle. Einige BPMN-Editoren lassen sich auch an Ihre Konventionen anpassen, so dass überflüssige Modellelemente aus der Toolbox entfernt werden.

Software auswählen

Die Auswahl eines geeigneten Software-Produkts steht ebenfalls nach der Festlegung der Ziele. Viele Tools sind zwar vielseitig aufgestellt, der Endanwender hat aber kaum eine Chance, die Features, die er für die Zukunft gerne in der Hinterhand hätte, bereits zum Kaufzeitpunkt ausführlich genug unter die Lupe zu nehmen. Einige Tools, wie z.B. Camunda zielen konsequent auf die Workflow-Automatisierung ab. Andere Tools bieten eine Reihe Features die wir im Rahmen einer Prozessanalyse gebrauchen können, wie z.B. Generierung von RACI-Diagrammen oder Nutzungsbeziehungen, wie es die Software IYOPRO vormacht.

Gut an der BPMN 2.0 ist ja, dass wir uns nicht abhängig von einer bestimmten Software machen. Sie beinhaltet ein standardisiertes XML-Format, mit dem wir unsere Modelle im- und exportieren können. Leider gilt das aber nur für einzelne Prozessmodelle und nicht etwa für ganze Projektmappen. Eine komplette Ordnerstruktur in ein anderes Tool zu überführen, mag unter Umständen etwas aufwändiger werden.

Fazit

Eine gemeinsame Kommunikationsgrundlage ist die BPMN 2.0, wenn man sie konsequent anwendet.

Es ist explizit gewünscht, Prozessmodelle, die ich mit einem bestimmten Zweck entworfen habe, später als Grundlage zu nehmen, wenn ich mich mit dem gleichen Prozessen unter einem anderen Aspekt auseinandersetze. Ich muss mir dann natürlich der damaligen und der aktuellen Ziele bewusst sein. Dann kann ich eine Menge Synergieeffekte mitnehmen.

Einige Software-Tools erlauben es sogar, auf ein dasselbe Prozessmodell abhängig vom Betrachtungszweck unterschiedliche Sichten einzunehmen. Entsprechend werden einzelne Elemente ausgeblendet. Änderungen die durch die Fachabteilung an einem Prozess vorgenommen wurden, schlagen sich somit auf alle interessenbezogenen Sichten für diesen Prozess durch.