Beiträge

Nachdem ich im letzten Artikel das Ebenenkonzept zur strukturierten Aufnahme von Prozessen vorgestellt habe, möchte ich in diesem Artikel den grundsätzlichen Aufbau der BPMN beschreiben. Denn, was so komplex anmutet und auf den einschlägigen Postern so erschlagend daherkommt, ist im Grunde einfach und übersichtlich aufgebaut. Zunächst schauen wir uns an, welche drei Diagrammtypen die BPMN zur Verfügung stellt. Dann stellen wir fest, dass zwei davon in der Praxis kaum relevant sind, und schauen uns schließlich die Inhalte des relevanten Diagrammtyps an. 

Die BPMN stellt drei grundsätzliche Diagrammtypen zur Verfügung: Das Prozessdiagramm, das Choreographiediagramm und das Kollaborationsdiagramm mit dem Konversationsdiagramm als Unterdiagramm. Das Choreographiediagramm und das Konversationsdiagramm haben zum Ziel, die Prozessbetrachtung auf den Nachrichtenfluss zu reduzieren bzw. in kompakter Form das Zusammenwirken der am Prozess Beteiligten darzustellen. Beide haben sich in der Praxis bisher nicht durchgesetzt und werden hier nicht weiter betrachtet.

Das Prozessdiagramm hingegen wird in private nicht ausführbare, private ausführbare und öffentliche Prozesse unterschieden. Um BPMN-konforme Diagramme zu erstellen, ist diese Unterscheidung allerdings nicht von Belang und soll ebenfalls nicht weiter betrachtet werden. Auch die Unterscheidung, dass aus einem Prozessdiagramm ein Kollaborationsdiagramm wird, sobald in der Darstellung mehr als ein Prozess und damit deren Kollaboration betrachtet wird, ist eher akademischer Natur und wird zunächst nicht weiter betrachtet. In der Übersicht sieht es dann so aus:

Prozessdiagramm

  • Private nicht ausführbare Prozess
  • Private ausführbare Prozesse
  • Öffentliche Prozesse

Choreographiediagramm

Kollaborationsdiagramm

  • Konversationsdiagramm
  • Prozessdiagramm mit mehr als einem Prozess
  • Kollaborationsdiagramm mit mehr als einem Prozess

Wir betrachten nur das private nicht ausführbare Prozessdiagramm und treffen keine Unterscheidung, wenn mehr als ein Prozess betrachtet wird.

Damit haben wir den verwirrendsten Teil schon hinter uns!

Aufbau der Symbolpalette

„It should be emphasized that one of the drivers for the development of BPMN is to create a simple and understandable mechanism for creating Business Process models, while at the same time being able to handle the complexity inherent to Business Processes. The approach taken to handle these two conflicting requirements was to organize the graphical aspects of the notation into specific categories.“ (Business Process Model and Notation, Version 2.0.2, Seite 25)

Schöner als die Spezifikation kann ich es nicht formulieren. Um diesen Ausgleich, zwischen einfachem Mechanismus und der Möglichkeit komplexe Zusammenhänge darzustellen, zu schaffen, unterscheidet die BPMN die Symbole in fünf Basiskategorien (Die Spezifikation spricht übrigens von Elementen (Elements) statt von Symbolen. Ich finde den Begriff Symbole im Deutschen aber treffender):

  • Flussobjekte (Flow Objects)
  • Daten (Data)
  • Verbinder (Connecting Objects)
  • Schwimmbahnen (Swimlanes)
  • Artefakte (Artifacts)

Anhand der fünf Basiskategorien möchte ich die Symbole des Basis-Levels des BPMN Wissen und Werkzeug Prinzips darstellen. Hier sollen die Symbole allerdings zunächst nur vorgestellt werden. Wie sie genau eingesetzt werden, stelle ich in den folgenden Artikeln ausführlich dar.

Die Flussobjekte

Die Flussobjekte werden unterteilt in:

  • Ereignisse (Events)
  • Aktivitäten (Activities)
  • Gateways.

Die Ereignisse bilden die umfangreichste Gruppe. Die Spezifikation sieht hier nicht weniger als 51 verschiedene Symbole vor. Für das Basis-Level begrenze ich diese Palette auf lediglich neun. Für eine fachliche Modellierung sind diese neun vollkommen ausreichend. Die Darstellung der Ereignisse folgt einer einfachen Logik. Der Rand des Ereignisses gibt an, ob es sich um ein Start-, Zwischen- oder Endereignis handelt. So haben Startereignisse einen dünnen Rand, Zwischenereignisse einen doppelten Rand und Endereignisse einen dicken Rand. Das Symbol innerhalb des Kreises gibt den Ereignistyp an.

Startereignisse

Zwischenereignisse

Endereignisse

Aktivitäten

Bei den Aktivitäten unterscheide ich lediglich den Task und den Unterprozess.

Auch bei den Gateways nehme ich Einschränkungen vor. So wird das komplexe Gateway nicht berücksichtigt und auch die Möglichkeit einen Prozess mit einem Gateway starten zu lassen, ist wenig intuitiv. Beides kann mit den Symbolen des Basis-Levels anschaulicher dargestellt werden. Übrig bleiben die folgenden Gateways.

Die Datenobjekte

Wenn Prozesse mit dem Ziel der Digitalisierung beschrieben werden, ist es wichtig, den Daten und Dokumentenfluss in das Modell mit aufzunehmen. Auf dem Basis-Level lässt sich dies mit drei einfachen Symbolen realisieren: Dem Dateninput, dem Datenoutput und dem Datenspeicher.

 

Die Verbinder

Um die einzelnen Symbole zu verbinden, werden in der BPMN, wie anderen Modellierungssprachen auch, Verbinder verwendet. Diese geben den Lauf des Prozesses oder den Lauf von Informationen an.

Schwimmbahnen

Der überwiegende Teil der erstellten BPMN-Modelle nutzt Pools und Schwimmbahnen. Diese geben Aufschluss über die Beteiligten und visualisieren die Schnittstellen, die sich in Prozessen häufig als Schwachstellen erweisen.

Pool mit Schwimmbahnen

Artefakte

Grundsätzlich erlaubt es die BPMN eigene Symbole hinzuzufügen. Diese würden dann als Artefakte bezeichnet. Ich rate aber davon ab, die BPMN selbst zu erweitern. Zumal Prozessmanagementsoftware in der Regel nicht die Möglichkeit bietet, eigene Symbole zu integrieren. Von Haus aus bringt die BPMN zwei Artefakte mit. Beide haben rein informativen Charakter und werden nicht in den Prozessfluss modelliert.

Damit sind alle Symbole des Basis-Levels des Wissen und Werkzeug Prinzips auch schon vorgestellt. Mit dieser übersichtlichen Palette an Symbolen können Sie für jeden Prozess ein fachliches Modell erstellen. In Kombination mit einigen einfachen Regeln, die ich noch im Detail vorstellen werde, können Sie sehr einfach BPMN Modelle erstellen, die zu 100% der Spezifikation entsprechen.

In den nächsten Artikeln werde ich nun jeweils vorstellen, wann und wie die einzelnen Symbole zu verwenden sind.

Eine Übersicht über die hier vorgestellten Symbole finden Sie hier.

„Strukturiertes Vorgehen bei der Prozessaufnahme“ ist einer der meist genannten Wünsche, wenn ich Erwartungen in meinen Seminaren abfrage. Vom Groben ins Feine (da ist es schon wieder) oder Neudeutsch Top-Down kann die Antwort lauten. Was aber verbirgt sich dahinter? Ohne weitere Erklärungen bringt uns die Antwort kaum weiter. Im zweiten Teil meiner Reihe zur BPMN möchte ich mein Ebenenmodell vorstellen und zeigen, wie ich die BPMN in eine solche Top-Down Methode einbette.

Was ist überhaupt mit Ebenenkonzept gemeint? In der Praxis hat es sich als nicht sinnvoll erwiesen, für einen Prozess ein einziges Modell auf Ebene der einzelnen Aktivitäten zu erstellen. Die Gründe hierfür sind vielfältig. Sie erstellen Prozesstapeten, auf denen völlig die Übersicht verloren geht, Zusammenhänge nicht mehr sichtbar sind, Sie selbst verzetteln sich bei der Prozessaufnahme und schließlich landet das Modell in der Schublade, weil es den erhofften Nutzen nicht stiftet. Der enorme Zeitaufwand kommt noch hinzu. Die Lösung ist eine Zerlegung der Prozesse vom Groben ins Feine und zwar nur soweit, wie es für den Modellierungszweck nötig ist.

Was sagen die anderen?

Prozesse iterativ vom Groben ins Feine aufzunehmen, ist in der Literatur unumstritten. Es lassen sich aber eine ganze Reihe von Ansätzen finden, die sich hauptsächlich in der Anzahl der Ebenen unterscheiden. Eine Übersicht hat Prof. Dr. Guido Fischermanns zusammengetragen:

Autoren Ebenenbezeichnungen
Bokranz/Kasten Unternehmensprozesse, Geschäftsprozesse, Teilprozesse, Arbeitsabläufe, Teilarbeitsabläufe, Unterarbeitsabläufe, Tätigkeiten
Gadatsch Geschäftsprozess, Geschäftsprozessschritte, Elementare Geschäftsprozessschritte
Gaitanides/Scholz/ Vrohlings/Raster Unternehmensprozess, Teilprozess, Ebene II, Teilprozess Ebene III, Arbeitsschritt, Aktivität
Schmelzer/Sesselmann Geschäftsprozess, Teilprozess, Prozessschritt, Arbeitsschritt
Nadig Prozess, Aktivität, Tätigkeit
Vahs Geschäftsprozess, Teilprozess 1. Ebene, Teilprozess 2. Ebene, Elementarprozess mit Aktivitäten

Tabelle 1 vgl. Fischermanns, Guido: Prasxishandbuch Prozessmanagement, Gießen, 11.Auflage, 2013

Etwas anderes empfehlen Freund und Jakob in Ihrem Werk „Praxishandbuch BPMN„. Zwar empfehlen sie ebenfalls ein Top-Down Vorgehen, unterscheiden aber nur strategische und operative Prozessmodelle und gliedern die operativen Modelle in so viele Unterprozesse, wie es in dem Projekt eben notwendig ist, ohne sich einem streng gegliederten Ebenenmodell zu unterwerfen. Die BPMN selbst gibt kein Ebenenkonzept vor, sie eröffnet aber die Möglichkeit, diese nach den eigenen Wünschen zu realisieren.

Ich selbst folge im Grunde dem Ansatz der KGSt, da er sich in der Praxis bewährt hat. Dieser unterscheidet Prozess, Prozesslandkarte, Teilprozesse und Aktivitäten. Die Ebene der Aktivitäten ergänze ich allerdings um den Ansatz von Freund und Jakob. Dies resultiert aus den Spezifika der BPMN und bietet die Möglichkeit ein einziges Prozessmodell für verschiedene Anwendungsszenarien zu erstellen, ohne die oben genannten Prozesstapeten zu erstellen. Nun, wie sieht das Konzept genau aus und wo kommt die BPMN ins Spiel?

Prozess

Am Anfang aller Untersuchungen steht immer die Prozessidentifikation. Dies ist keinesfalls ein trivialer Vorgang. Als Beispiel möchte ich einen einfachen Antragsprozess, den BAföG-Antrag betrachten. Beginnt der Prozess mit dem Eingang des Antrages oder gehört die in vielen Fällen vorher stattfindende Beratung mit dazu? In der Literatur existieren verschiedene Definitionen für einen Prozess. Unstrittig ist aber, dass im Prozessmanagement die Kundenperspektive zählt und Prozesse End-to-End betrachtet werden. Soll heißen, Prozesse werden vom Auslöser, in der Wirtschaft in der Regel der Wunsch des Kunden, bis zur Erfüllung seines Wunsches betrachtet. Für den BAföG-Prozess heißt das, die Beratung ist einzubeziehen.

Auch das Ende des Prozesses muss genauer betrachtet werden. Endet der Prozess mit dem Bescheid oder gehören laufende Zahlung, regelmäßige Überwachung des Einkommens der Eltern usw. dazu? Betrachten wir End-to-End, so Endet der Prozess erst, wenn die letzte Zahlung geleistet ist und der Vorgang archiviert wurde. Wichtig sind also die Definition des Auslösers und des Ergebnisses des Prozesses. Definieren Sie diese möglichst genau und beschreiben Sie diese als einen eingetretenen Zustand („Kunde möchte BAföG-Antrag stellen“). Der Prozess selbst wird mit einem Substantiv und Verb benannt, also z. B. „BAföG-Antrag bearbeiten.“

Eine grafische Darstellung hat sich auf dieser Ebene in der Praxis nicht bewährt. Sie bringt keinen Erkenntnisgewinn, vielmehr sollte ein Prozessstammblatt angelegt werden.

Prozesslandkarte

Rufen Sie sich das Motto „vom Groben ins Feine“ ins Gedächtnis, so wäre es denkbar, dass die Prozesslandkarte doch über dem Prozess stehen müsste. Jedoch können Sie keine Prozesslandkarte erstellen, ohne vorher die Prozesse identifiziert zu haben. Im Gegensatz zur freien Wirtschaft halte ich es in der öffentlichen Verwaltung nicht für sinnvoll, eine unternehmens- bzw. verwaltungsweite Prozesslandkarte zu erstellen. Ich empfehle Ihnen auf der Produktebene, eine Prozesslandkarte zu erstellen oder, wenn Sie projektbezogen einen Prozess betrachten, eine auf diesen Prozess bezogene Prozesslandkarte zu erstellen. Die BPMN sieht für die Erstellung einer Prozesslandkarte keine Symbole vor. Im Wissen und Werkzeug Prinzip werden Prozesslandkarten deshalb nicht mit Hilfe der BPMN erstellt. Wie genau Prozesslandkarten erstellt werden, stelle ich in einem gesonderten Artikel vor.

Teilprozesse

Ab dieser Ebene arbeiten wir mit der BPMN und erstellen mit der Spezifikation vollkommen im Einklang stehende Prozessmodelle. Eine feste Regel wie Teilprozesse abgegrenzt werden, gibt es nicht. Bei mir haben sich in der Praxis allerdings zwei Merkmale zur Abgrenzung bewährt. Zum einen endet bei mir ein Teilprozess immer dann, wenn der Prozess die Grenze einer Organisationseinheit überschreitet. In der Regel liegt an dieser Stelle ein definierbares Zwischenergebnis vor. Außerdem handelt es sich um eine Schnittstelle. Diese sollten bei Prozessprojekten grundsätzlich betrachtet werden. Zum anderen definiere ich in der Regel einen neuen Teilprozess, wenn der Prozess eine (planmäßige) längere zeitliche Unterbrechung aufweist. Hier können als Beispiele der Versand einer Anhörung und die Anforderung von Stellungnahmen genannt werden. Dies sind natürlich keine abschließenden Regeln, es kann im Prozess andere Ereignisse geben, die es rechtfertigen, einen neuen Teilprozess zu definieren.

Der bei der Prozessidentifikation definierte Auslöser des Prozesses, muss immer auch der Auslöser des ersten Teilprozesses sein. Falls Sie feststellen, dass die beiden nicht übereinstimmen, so müssen Sie eine der Ebenen anpassen. In der Praxis ist es nicht selten der Fall, dass sich Auslöser und Ergebnis bei genauerer Betrachtung nochmal verändern. Wichtig ist aber, dass beide am Ende auf allen Ebenen übereinstimmen. Folglich muss das Ergebnis des letzten Teilprozesses auch das Ergebnis des Gesamtprozesses sein.

Zwischen den Teilprozessen werden nach dem Wissen und Werkzeug Prinzip Ereignisse definiert. Diese müssen Sie sich als Zwischenergebnisse vorstellen. Stellen Sie sich die Frage, welcher Zustand eingetreten ist, wenn der Teilprozess beendet ist, bzw. welcher Zustand vorliegen muss, damit der nächste Teilprozess starten kann. Legen Sie bei der Definition des Zwischenergebnisses eine hohe Genauigkeit an den Tag. Schmelzer und Sesselmann sehen Schnittstellen innerhalb eines Prozesses als Quelle organisatorischer Unverantwortlichkeit. Grenzen Sie die Teilprozesse exakt ab, so haben sie bereits exakt den Punkt beschrieben, an dem die Verantwortung von der einen auf die andere Organisationseinheit übergeht. Allein dadurch können schon enorme Prozessverbesserungen realisiert werden. Wenn Sie nun im zweiten Schritt noch Qualität und Güte des Zwischenergebnisses definieren, haben Sie bereits einen massiven Mehrwert geschaffen. Nehmen Sie sich einige Minuten, denken Sie an Ihre eigene Zusammenarbeit mit anderen Organisationseinheiten und lesen Sie den letzten Absatz noch einmal.

Das Teilprozessmodell zähle ich zu den strategischen Prozessmodellen. Es dient dazu, einen Überblick über den Prozess, seine Beteiligten und Abhängigkeiten sowie Austausch zwischen diesen zu geben. Zielgruppe sind in der Regel Führungskräfte. Wobei ich die Ebene der Teilprozesse auch häufig für Personalbedarfsermittlungen nutze. Halten Sie das Modell also schlank. Es sollte idealerweise auf eine oder zwei DIN A4 Seiten passen. Details werden hier ausdrücklich ausgeblendet! Sollten in einem Teilprozess Prüfungen wie die Vollständigkeit, Zuständigkeit oder das Vorliegen formaler Voraussetzungen stattfinden, so werden die Prozessergebnisse, sollte eine der Prüfungen negativ ausfallen, nicht modelliert. Nicht, dass es zu Missverständnissen kommt: Die genannten Prüfungen sind keine Teilprozesse, vielmehr sind diese häufig Inhalt eines einzigen Teilprozesses.

Wie so ein Prozessmodell aussehen kann, zeige ich am Beispiel einer meiner eigenen Prozesse: Seminar durchführen. Welche Symbole, wie eingesetzt werden, erläutere ich, wenn ich im nächsten Artikel die Symbolpalette des Basis-Levels vorstelle.

Aktivitäten

Sind die Teilprozesse definiert, können diese nun auf Aktivitätenebene weiter zerlegt werden. In diesem Schritt wechseln wir von den strategischen Prozessmodellen zum operativen Prozessmodell. Als größte Schwierigkeit wird hier häufig die richtige Detailtiefe des Modells empfunden. Eine allgemeingültige Regel kann nicht aufgestellt werden. Der Modellierungszweck bestimmt sowohl, wie detailliert der Prozess auf Aktivitätenebene beschrieben werden muss, als auch, welche Teile des Prozesses detaillierter betrachtet werden. Ein Prozessmodell, welches zur Entwicklung eines Workflows erstellt wird, weist eine andere Tiefe auf und legt den Fokus auf andere Informationen, als ein Modell, welches zum Risikomanagement erstellt wird. Um den „richtigen“ Detailgrad zu treffen, sollten Sie sich vor Beginn der Prozessaufnahme zwei Fragen stellen.

Wozu soll das Prozessmodell dienen?

Welche Informationen muss das Modell dazu enthalten?

Wenn Sie nur solche Teile des Prozesses detailliert beschreiben, die für Ihren Modellierungszweck einen informatorischen Mehrwert haben, verhindern Sie, das Modell mit Informationen aufzublähen, die Sie eigentlich nicht brauchen. Dadurch sparen Sie nicht nur Zeit, Sie verstellen auch nicht den Blick auf das Wesentliche durch unnötige Informationen.

Als weiteres Hilfsmittel, den Prozess übersichtlich zu gestalten, dienen die sogenannten Unterprozesse. Diese sind nicht mit den Teilprozessen zu verwechseln. Mit Unterprozessen lassen sich Aktivitäten kapseln und zwar in eine solche Tiefe, wie es für den Modellierungszweck eben notwendig ist. Zur Arbeit mit Unterprozessen werde ich noch einen eigenen Artikel schreiben und erläutern, welche Regeln bei der Arbeit mit Unterprozessen zu beachten sind.

Das Ebenenmodell in der Übersicht

Und in der Praxis?

In der freien Wildbahn sind Projekte leider nicht immer so durchzuführen, wie es die Lehrbücher vorschlagen. Das hier beschriebene Vorgehen ist aber eines der wenigen, das ich in jedem Prozessprojekt anwende. Argumente wie Zeitdruck lasse ich hier nicht gelten, da sich die investierte Zeit in jedem Fall auszahlt. Steigen Sie gleich auf der Ebene der Aktivitäten ein, so holt Sie die mangelnde Übersicht im Laufe des Projektes ein und verursacht zusätzliche Arbeit. Zumal die Identifikation des Prozesses, die Erstellung einer Prozesslandkarte und die Definition der Teilprozesse, mit ein wenig Übung, nicht besonders viel Zeit erfordern. Ich kenne kaum ein Vorgehen, welches ein besseres Aufwand-Nutzen-Verhältnis aufweist als dieses. Dies gilt insbesondere, wenn Sie, wie oben schon beschrieben, den Prozess nur soweit zerlegen, wie es für ihren Modellierungszweck notwendig ist. Bei Personalbedarfsermittlungen beispielsweise reicht es häufig aus, den Prozess nur bis zu den Teilprozessen zu zerlegen und auf dieser Ebene die Bearbeitungszeiten zu ermitteln.

Damit sind die theoretischen Grundlagen gelegt. Im Nächsten Teil werde ich die BPMN-Symbole des Basis-Levels vorstellen.

„Die Norm dient dazu, die Sinnbilder für die Datenfluß- und die Programmablaufpläne zu vereinheitlichen. […] Eine allgemeine Verständigung mit Hilfe dieser Pläne und ihr Austausch zwischen verschiedenen Stellen ist jedoch nur dann ohne Schwierigkeiten möglich, wenn überall einheitliche Sinnbilder benutzt werden. Um dieser Forderung willen wurde die vorliegende Norm ausgearbeitet.“ Dieses Zitat stammt aus der bereits 1966 veröffentlichten DIN-Norm „Sinnbilder für Datenfluß und Programmablaufpläne“ und beschreibt ein Problem das in der deutschen Verwaltung noch aktuell ist, sich global gesehen aber immer mehr zu erledigen scheint. Das Problem: Der Austausch von Prozessmodellen. Die Lösung: Der de facto Standard BPMN 2.0.


Als meine Mutter noch in die Grundschule gegangen ist, wurde also schon eine Norm veröffentlicht, die Symbole und deren Bedeutung zur Erstellung von Flussdiagrammen definiert. Umso überraschender ist es, dass bis heute in der öffentlichen Verwaltung kein einheitlicher Standard zur Beschreibung von Prozessen festgelegt ist. Vielmehr wurden Mitte der Nullerjahre zwei Notationen explizit für die öffentliche Verwaltung entwickelt. So hat die KGSt in Zusammenarbeit mit der bit-Consult den Fachmodellierungsstandard (FaMoS) und die Picture GmbH als Spin Off der Uni Münster die Picture Methode entwickelt. Beide Notationen sind heute insbesondere im kommunalen Bereich verbreitet.

Digitalisierung als Treiber

Mit zunehmender Digitalisierung wurde das Bedürfnis einer Notation, die sowohl von Organisatoren als auch von der IT gelesen, verstanden und genutzt werden kann, größer. Dazu wurde an eine solche Notation der Anspruch gestellt, automatisiert in maschinenlesbaren Code überführt werden zu können. Daran hatten insbesondere die großen IT- und Softwarehäuser Interesse und diese sind es denn auch, die mit anderen zusammen 1989 die Object Management Groupgegründet haben. Diese entwickelt herstellerunabhängige und systemübergreifende Standards zur Programmierung und eben auch zur Darstellung von Geschäftsprozessen. Die durch den IBM Mitarbeiter Stephen A. White entworfene Notation BPMN (Business Model and Notation) wird seit 2005 von der OMG gepflegt und weiterentwickelt. Mittlerweile liegt die BPMN in der zweiten Version vor und kann als der weltweit anerkannte de facto Standard bezeichnet werden.

Verbreitung in der öffentlichen Verwaltung

Auch in der öffentlichen Verwaltung erfährt die BPMN zunehmende Verbreitung. In der Schweiz beispielsweise ist die BPMN über alle Ebenen der Verwaltung hinweg als Standard definiert worden. Auch das Bundesverwaltungsamt nutzt die BPMN als Standard zur Modellierung. Hier wird Sie allerdings nur für IT-Modelle genutzt. Warum die fachlichen Modelle mit der Ereignisgesteuerten Prozesskette (EPK) erstellt werden und die Modelle so übersetzt werden müssen, erschließt sich mir nicht. Genau genommen läuft dies dem Gedanken der BPMN komplett entgegen, denn Sie wurde ja gerade dafür entwickelt, dass Fachabteilung und IT „dieselbe Sprache sprechen“. Besser macht es Nordrhein-Westfalen: In Verbindung mit §12 Absatz 2 EGovG NRW „Vor Einführung der elektronischen Vorgangsbearbeitung sollen Behörden des Landes Verwaltungsabläufe unter Nutzung einer landeseinheitlichen Methode dokumentieren, analysieren und optimieren.“ hat das Ministerium für Inneres und Kommunales Folgendes erlassen: „Zur Dokumentation, Analyse und Optimierung von Geschäftsprozessen in der Landesverwaltung ist die Notation des Standards BPMN 2.0 (Business Process Model and Notation) zu verwenden.“ Andere Bundesländer haben bereits Ähnliches erlassen. Die bundesweite Standardisierung auf Ebene des Bundes und der Länder scheint also nur noch eine Frage der Zeit.

Und was machen die Kommunen?

Die Situation bei den Kommunen stellt sich sehr heterogen dar. Die beiden Notationen FaMoS und Picture werden über die ganze Republik verteilt eingesetzt. Die in der öffentlichen Verwaltung recht weit verbreitete Prozessmanagementsoftware Adonis bringt – wie sollte es auch anders sein – eine eigene Notation mit und diese wird ebenfalls gern verwendet. Dazu gesellen sich weitere herstellerspezifische Notationen und schließlich noch die EPK. Ich selbst modelliere im dienstlichen Umfeld mit dem FaMoS-Standard. Aus damaliger Sicht war dies sicherlich eine gute Entscheidung. Die Kommunen werden sich allerdings unisono die Frage stellen müssen, ob ein Wechsel zur BPMN nicht sinnvoll ist. Die Picture GmbH beispielsweise bietet mittlerweile eine „Picture BPMN“ Version an. Leider ist auf der Homepage dazu nur Marketing-Sprech ohne wirklichen Inhalt zu finden. Es existiert zwar ein Video zum Modellieren mit Picture BPMN, wenn das dort zu sehende allerdings alles an BPMN ist was integriert wurde, lügt die Homepage zumindest nicht.

Komplexität der BPMN

Es ist wahr, die BPMN kann sehr komplex sein. Immerhin hat sie den Anspruch Geschäftsprozesse, gleich aus welcher Branche, detailliert beschreiben und alle Eventualitäten, die auftreten können, darstellen zu können. Davon sollten Sie sich allerdings nicht abschrecken lassen. Die Spezifikation der BPMN selbst unterscheidet drei Ebenen von Prozessmodellen: Die deskriptive Ebene zur reinen Beschreibung von Prozessen, die analytische Ebene für Prozessanalysten und die ausführbare Ebene für IT-Spezialisten. Die Anzahl der Symbole und die Komplexität der Anwendung steigt von Ebene zu Ebene, wobei die ersten beiden Ebenen (Zielgruppen: Fachbereiche und Organisatoren) nicht wesentlich komplexer in der Anwendung sind als die oben genannten Notationen.

Dieser Artikel stellt den Auftakt einer Reihe zur Modellierung mit der BPMN dar. In dieser Reihe werde ich die Grundlagen der Modellierung mit der BPMN erläutern und eine Rahmenstruktur vorstellen, die die BPMN auf die Bedürfnisse von Verwaltung zuschneidet, sich dabei aber vollständig im Rahmen der Spezifikation der BPMN bewegt! Letzteres ist elementar, da nur so die herbeigesehnte Austauschbarkeit der Modelle gewährleistet werden kann.