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.

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

 

Auf dem Weg von einer funktional zu einer prozessorientiert organisierten Verwaltung wird häufig über die Prozessverantwortung diskutiert. Dies ist ein sensibles Thema, da es hier um die Verschiebung – mindestens fachlicher – Weisungskompetenz geht. Dabei wird in der Regel nur die Situation nach der Optimierung betrachtet, also wenn die Abläufe festgelegt sind und „nur“ noch gesteuert werden muss. Dass zur Prozessverantwortung auch die Festlegung der Abläufe und die Einführung von Standards gehört, wird dabei häufig übersehen.

Den optimalen Soll-Prozess gibt es für keinen Prozess. Die Determinanten Qualität, Kosten und Zeit bedingen sich und müssen in der Regel gegeneinander abgewogen werden. So unterscheidet sich der optimale Soll-Prozess von Kommune zu Kommune in Abhängigkeit von der konkreten Zielsetzung. Ich möchte das an einem Beispiel deutlich machen. Ein interner papiergebundener Antrag, der verschiedene Ämter durchläuft soll digitalisiert werden. In der analogen Welt steht es außer Frage, dass alle Anträge über den Schreibtisch des Vorgesetzten gehen und von dort aus auf die jeweiligen Sachbearbeitenden verteilt wird. Im Zuge der Soll-Modellierung kommt nun die Frage auf, ob dies auch in die digitale Welt übertragen werden soll. Gehen die Anträge in Zukunft direkt an die Sachbearbeitenden und werden dem Vorgesetzen bearbeitet zur Mitzeichnung vorgelegt, so lässt sich die Durchlaufzeit deutlich verkürzen. Vorgesetzte sehen hier aber die Gefahr, dass in ihrem Verantwortungsbereich Anträge bearbeitet werden von denen sie keine Kenntnis haben. Bleibt man bei der hergebrachten Verfahrensweise so ist im Bezug auf die Durchlaufzeit nur wenig gewonnen.

In Spannugsverhältnissen dieser Art sind bei der Soll-Modellierung in der Regel etliche Entscheidungen zu treffen.Aufgabe des Modellierers sollte es nun sein die verschiedenen Alternativen mit dem jeweiligem Vor- und Nachteilen – eventuell mit einem Entscheidungsvorschlag – den Entscheidungsträgern vorzulegen.

Die Praxis sieht oft anders aus

In der Praxis ist es häufig so, dass Entscheidungsträger einen in allen Belangen optimierten Soll-Prozess erwarten und im Zuge des Projektes die Entscheidungsgewalt faktisch auf den Modellierer übertragen. In dem Augenblick wird auch die faktische Prozessverantwortung auf den Modellierer übertragen.
Der Modellierer legt nun fest wer, was wann und die bearbeitet. Er erarbeitet zusammen mit den ausführenden Stellen Standards und Qualitätsanforderungen und gießt all dies in ein Soll-Modell.

Damit meine ich keineswegs, dass dem Modellierer zusätzliche Kompetenzen im Sinne der Dienstverteilung verliehen werden. Vielmehr wird ihm dies zuteil, da er ein fertiges Modell vorlegen soll, statt einiger Entscheidungsalternativen. Dieses nimmt natürlich noch seinen Weg durch die Instanzen bevor es umgesetzt wird und bekommt so seine Legitimation. Im schlimmsten Fall werden auf diesem Weg noch Anpassungen am Modell vorgenommen, die aus Sicht des einzelnen Sinn haben mögen, häufig aber die Sicht auf den Gesamtprozess vernachlässigen. Den einzelnen Entscheidungsträgern ist dabei nicht mal ein Vorwurf zu machen, da mangels Abwägungsdarstellungen, die einzelne Entscheidung für einen Ablauf gar nicht nachvollzogen werden können. In der Praxis passiert nun das was von Beginn an hätte gemacht werden sollen. Das Modell wird gemeinsam besprochen, verschiedene Alternativen geprüft und es ist nicht unwahrscheinlich, dass am Ende das ursprünglich vorgelegte Soll-Modell beschlossen wird.

Damit ist die Arbeit des Modellierers aber noch nicht getan. Neben der Verantwortung für die Umsetzung (auf die ich an dieser Stelle nicht eingehen möchte) bleibt die Prozessverantwortung auch über die Umsetzungsphase hinaus noch bestehen. Er ist nun derjenige, der den Prozess im Detail kennt und mindestens bei Fragen zum Ablauf konsultiert wird, nicht selten aber auch zu fachlichen Fragen Stellung nehmen soll. Wieder liegt die faktische Prozessverantwortung beim Modellierer.

Wie kann eine Alternative aussehen?

Der Modellierer sollte in der Kommune als Dienstleister betrachtet werden. Er verfügt über das Wissen die richtigen Werkzeuge richtig anzuwenden. Er beschreibt den Prozess, wägt ab, erarbeitet – im Idealfall mit den Fachleuten vor Ort – Alternativen und legt diese vor. Er steht den Entscheidungsträgern als Berater zur Seite, da er den Gesamtüberblick über den Prozess hat. Er fungiert als Schnittstelle zwischen den beteiligten Fachämtern und der IT, falls diese beteiligt ist. In der Umsetzungsphase kann er die Koordination des Umsetzungsprojektes übernehmen, nicht aber die Projektverantwortung. Nach erfolgter Umsetzung sollte er weiterhin als Berater zur Verfügung stehen. Die kontinuierliche Verbesserung des Prozesses liegt aber in der bestenfalls schriftlich fixierten Verantwortung des Prozessverantwortlichen vor Ort.