Beiträge

„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.

Über die BPMN wird im kommunalen Umfeld in letzter Zeit viel gesprochen. Manches davon stimmt sogar, vieles aber auch nicht. Um der Wahrheit auf den Grund zu gehen, gibt es aber nicht nur einen Lichtblick, es gibt einen strahlenden Sonnenschein der Erleuchtung: Die Spezifikation der BPMN. Die von der Object Management Group herausgegebene Spezifikation der BPMN – und nur sie – definiert Syntax und Semantik der BPMN! Wozu dann noch ein Wissen und Werkzeug Prinzip? Antworten gibt dieser Artikel.


Ich habe im letzten Artikel bereits erwähnt, dass die BPMN sehr komplex sein kann und eine umfangreiche Symbolpalette mitbringt. Als wäre das nicht schon genug, lässt der strahlende Sonnenschein der Erleuchtung (die Spezifikation) auch noch die Möglichkeit, den gleichen Sachverhalt auf unterschiedliche Art und Weise zu modellieren. Um den Einstieg in die BPMN zu erleichtern und gleiche Sachverhalte möglichst gleich zu modellieren, habe ich das Wissen und Werkzeug Prinzip entwickelt.

Der Grundsatz: Artikel 1 des Wissen und Werkzeug Prinzips

Die Spezifikation der BPMN ist unantastbar! Ich gebe zu: Es ist etwas hochtrabend und überspitzt formuliert, aber als Grundsatz gilt: Alle Regeln halten sich streng an die Spezifikation. Nach dem Wissen und Werkzeug Prinzip erstellte Prozessmodelle sind demnach 100% mit der Spezifikation konform! Daraus ergibt sich, dass die Bedeutung der Symbole nicht angetastet wird. Ich beschränke lediglich den Umfang der Symbole und mache einen Vorschlag, wie bestimmte Sachverhalte modelliert werden sollten.

Zwei Level der Modellierung

Was die Einschränkung der Symbolpalette betrifft, streiche ich natürlich keine Symbole. Vielmehr führe ich zwei Level der Modellierung ein. Das Basis-Level, mit allen Symbolen, die für eine fachliche Modellierung benötig werden, und das Experten-Level, das alle zur Verfügung stehenden Symbole beinhaltet. Die BPMN selbst sieht eine Dreiteilung in eine beschreibende Ebene (Descriptive), eine analytische (Analytic) und eine ausführbare Ebene (Common Executable) vor. Hierbei wird aber eine stark technische Sicht eingenommen und die Einteilung richtet sich hauptsächlich an Softwarehersteller. Mir war es wichtig ein Prinzip zu schaffen, mit dem sowohl in der Organisation, in der Fachabteilung als auch in der IT Modelle erstellt werden können, die leicht zu erstellen und für alle verständlich sind. Dazu musste ich einen Ausgleich zwischen Komplexität, Präzision und Verständnis des Modells finden. Ob mir dies gelungen ist, beurteilen Sie am besten selbst.

Die Münze

Die formale Korrektheit eines BPMN-Diagramms lässt sich am besten mit Hilfe einer Münze (im Englischen: Token) überprüfen. Stellen Sie sich vor, jede Prozessinstanz (z. B. ein Antrag) erzeugt eine Münze, die durch den Prozess wandert. Sequenzflüsse, Verzweigungen, Ereignisse etc. sagen der Münze was sie zu tun hat und wie sie weiter-wandert. In Seminaren mache ich eine Übung, in der ich die Teilnehmenden mit einer Münze Modellierungsfehler im Prozess suchen lasse. Der Erkenntnisgewinn dieser einfachen Methode ist nicht zu unterschätzen. Die Spezifikation selbst, wie auch der überwiegende Teil der BPMN-Literatur, verwendet dieses Verfahren. Die genaue Funktionsweise erläutere ich am folgenden Beispiel.

Beispiel Exklusive-Verzweigung

Damit sich jeder vorstellen kann, was ich meine, wenn ich sage, dass der gleiche Sachverhalt auf unterschiedliche Weise modelliert werden kann, möchte ich ein Beispiel anführen. So lässt sich eine Exklusive-Verzweigung auf folgende Arten darstellen.

Wobei hier schon der Teufel im Detail steckt. Im vorliegenden Beispiel haben alle drei Modelle tatsächlich die gleiche Bedeutung, da sich die Bedingungen ausschließen, was sie beim linken und mittigen Beispiel auch müssen, sonst läge ein Modellierungsfehler vor. Die bedingten Sequenzflüsse (rechts) könnten allerdings auch für die Modellierung einer Inklusiven-Verzweigung stehen. Ein Detail, das sich nicht intuitiv erschließt, weshalb bedingte Sequenzflüsse im Wissen und Werkzeug Prinzip keine Verwendung finden. Das linke und mittige Beispiel unterscheiden sich aber tatsächlich nur in der Darstellung, da die BPMN zwei Symbole für die Exklusive-Verzweigung kennt.

Was würde die Münze hier tun? Trifft die Münze auf eine Exklusive-Verzweigung (links + Mitte), so muss sie sich für genau einen Weg entscheiden. Könnte Sie sich für zwei Wege gleichzeitig entscheiden (z. B. Beträge überschneiden sich), läge ein Modellierungsfehler vor. Im rechten Beispiel wäre eine Überschneidung aus formaler Sicht allerdings kein Modellierungsfehler. Die Münze würde sich teilen und beide Wege gehen. Solche Feinheiten sind eher etwas für Modellierungsexperten und führen im Alltag in der Zusammenarbeit mit den Fachämtern nur zu Verwirrung. Ein simples Beispiel für die Sinnhaftigkeit einer Konvention wie sie das Wissen und Werkzeug Prinzip darstellt.

Ausblick auf die Reihe zur BPMN

Damit ist der Grundstein gelegt. Alle Vorgaben und Empfehlungen meines Prinzips entsprechen der Spezifikation der BPMN. Zudem führe ich zwei Level der Modellierung mit unterschiedlichen Symbolumfängen ein, damit auf dem Basis-Level eine einfache, verständliche und leicht zu erlernende fachliche Modellierung möglich ist und dem Experten auf dem Experten-Level alle Möglichkeiten der BPMN zur Verfügung stehen.

Im weiteren Verlauf der Reihe werde ich zunächst den grundsätzlichen Aufbau der BPMN erläutern, um im Anschluss die Symbolpalette des Basislevels vorzustellen. Dabei werde ich die Bedeutung und den korrekten Einsatz jedes einzelnen Symbols erläutern und mit Beispielen unterfüttern.

Sollten Sie es jetzt nicht mehr erwarten können, die Symbolpalette des Basis-Levels kennen lernen zu wollen, so empfehle ich das Abonnement meines Newsletters. Auf der Bestätigungsseite ist ein Link hinterlegt. Sollten Sie schon Abonnent sein, so finden Sie den Link im aktuellen Newsletter.

 

„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.