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.

Eine Kommune, ein Prozess, 1000 Ausprägungen! Zugegebenermaßen ist 1000 Ausprägungen etwas überspitzt formuliert, schauen wir uns allerdings kommunale Querschnittsprozesse an, so beschleicht uns das Gefühl, es könne doch wörtlich gemeint sein. Soll ein solcher Prozess nun in einen elektronischen Workflow gegossen werden, so wird häufig viel Zeit und Geld investiert, um all diese Ausprägungen abzubilden. Der Weg den Prozess zu standardisieren, was natürlich Veränderungen nach sich zieht, wird häufig gescheut. Warum eigentlich? Ein Erklärungsversuch…

Wir haben kürzlich in einem Seminar über die Entwicklung eines elektronischen Rechnungsworkflows gesprochen. Die Pilotkommune hat den Prozess in einer Organisationeinheit aufgenommen und gemeinsam mit dem Rechenzentrum einen Prototypen entwickelt. Als dieser Prototyp nun in einer anderen Organisationseinheit derselben Kommune getestet wurde, wurde schnell klar, dass die Abläufe nicht passen und der Workflow so nicht verwandt werden könne. In anderen Organisationseinheiten existierten noch weitere Varianten eine Rechnung zu begleichen. Wie selbstverständlich war die Anforderung der Kommune alle Varianten in den Workflow zu implementieren.

Ähnliche Erfahrungen habe ich selbst auch gemacht. Derselbe Prozess, läuft in derselben Kommune, in verschiedenen Organisationseinheiten, verschieden ab und die erste Reaktion ist, all diese Varianten in den Workflow einzubauen. Ich halte dies für Dauer und Erfolgsaussichten des Projektes fatal. Ganz zu schweigen vom Pflege- und Administrationsaufwand, sollte der Workflow doch jemals eingeführt werden. Warum wird der andere Weg, die Varianten so weit wie möglich zu reduzieren oder besser noch ein einheitliches Vorgehen zu entwerfen, so häufig nicht gegangen?

Aufwand, Widerstände, mutlose Entscheidungen

In meinen Augen sind dafür drei Dinge ausschlaggebend: Aufwand, Widerstände und fehlender Mut zu Entscheidungen. Es darf nicht verschwiegen werden und sollte jedem zu Beginn eines solchen Projektes bewusst sein, dass die Standardisierung von Prozessen einen nicht zu unterschätzenden Aufwand bedeutet. By the Way kann so ein Projekt in der Regel nicht durchgeführt werden. Auf allen Seiten müssen die personellen Aufwände geschätzt und vor allem bereitgestellt werden. Ist dafür eigentlich keine Zeit, es „muss“ aber gemacht werden, dann lassen Sie es lieber sein. Wird keine Zeit zur Verfügung gestellt, muss es auch nicht gemacht werden! Geht es Ihnen allerdings ähnlich wie mir und es hört ja keiner auf Sie, so machen Sie diesen Umstand wenigstens deutlich.

Die Straße des geringsten Widerstandes ist nur am Anfang asphaltiert

Gehen wir von guten Projektvoraussetzungen aus so bleiben immer noch die scheinbar unüberwindbaren Widerstände. Die Gründe weshalb die einzelne Organisationseinheit einen Prozess auf eine bestimme Weise abarbeitet können noch so nachvollziehbar oder unverständlich, so sinnvoll oder abwegig sein, sie sind da. Und es kommt noch dicker: Diese Verfahrensweise ist die die Gewohnte! Möchten Sie diese Gewohnheiten verändern ist mit Widerständen zu rechnen. Dabei gilt grundsätzlich: Je größer die Veränderung, je größer die Widerstände. Die Veränderungen im oben genannten Prozess betreffen die beiden Bereiche technische Unterstützung und organisatorischer Ablauf. Die Widerstände gegen Digitalisierung und technische Unterstützung sind stark rückläufig. Die zunehmende Digitalisierung, ich denke hier spielt besonders die Digitalisierung im Privatleben eine Rolle, sehe ich als Grund hierfür. Außerdem ist der Mehrwert für die Mitarbeitenden häufig greifbarer.

Die größeren Widerstände treten bei der Veränderung der Gewohnheiten auf. Um diese zu umgehen wird die Technik den Abläufen abgepasst. Man kann auch die grundsätzliche Frage stellen, ob die Technik dem Menschen oder der Mensch der Technik folgen soll. Im genannten Beispiel des Rechnungsworkflows muss die Entscheidung zugunsten „die Technik muss dem Menschen folgen“ ausgefallen sein. Auch wenn eine befriedigende Antwort auf die Frage differenzierter ausfiele, so stimme ich dem Paradigma „Technik folgt dem Menschen“ grundsätzlich zu. Allerdings muss die Technik nicht jedem Weg eines jeden einzelnen folgen. Vielmehr muss festgelegt werden welchen Weg der Mensch gehen will und diesem folgt die Technik. Und genau in dieser Einigung liegt die Herausforderung.

Fällt die Darstellung des Mehrwertes für die technischen Anpassungen noch relativ leicht, so bietet die Argumentation für einen standardisierten Ablauf in der Regel größere Herausforderungen. Es ist gut möglich, dass alle beteiligten Akteure ihre Vorgehensweise anpassen müssen, da keine der bisherigen aus Perspektive der gesamten Organisation ideal ist. Dass der Organisator diese Perspektive einnimmt ist für Querschnittsprozesse elementar und vereinfacht die Sache nicht. Dadurch kann es vorkommen, dass die organisatorischen Anpassungen aus Sicht eines Einzelnen erstmal keinen Mehrwert erzeugen, für die Gesamtorganisation aber sehr wohl. Auf die Frage des Einzelnen: „Und was hab ich davon?“ kann die Antwort also durchaus „Erstmal nichts“ lauten. Aber lassen Sie sich nicht entmutigen, die Einsicht, werden die Vorteile für das große Ganze schlüssig vorgetragen sind in der Regel größer, als es sich die Beteiligten selbst eingestehen wollen.

Beispiel Reisekosten

Für letztgenanntes ist die Einführung einer elektronischen Reisekostenabrechnung ein gutes Beispiel. Die Abschaffung der Papierfahrtenbücher hatte für fahrtenbuchführende Kolleginnen und Kollegen zur Folge, dass diese das im Wagen geführte Fahrtenbuch nun nicht mehr einfach bei der Reisekostenabrechnung abgeben konnten, sondern alle Fahrten am Arbeitsplatz im System erfassen mussten. Für die Mitarbeitenden also eine echte Mehrbelastung. Dennoch waren die Widerstände gering. Zum einen hatte das mit der oben genannten fortschreitenden Digitalisierung zu tun. Zum anderen war einzusehen, dass es aus Sicht der Gesamtorganisation einige Vorteile hat, wenn die von jedem digital erfassten Daten automatisiert verarbeitet werden können, statt jedes handgeschriebene Fahrtenbuch einzeln händisch auszuwerten.

Schließlich bin ich der Überzeugung, dass Hans Kapser mit der Aussage: „Die Straße des geringsten Widerstandes ist nur am Anfang asphaltiert.“ richtig liegt. Wenn Sie den Aufwand und die Widerstände meiden, holen diese Sie ein und am Ende steht ein gescheitertes Projekt, eine Anwendung die nie richtig ans Laufen kommt und deutlich mehr Arbeit verursacht als wären Sie die Standardisierung angegangen.

Sie Sache mit den Entscheidungen

Eine Verwaltung ist eine verworrene Gemengelage aus unterschiedlichsten Interessen. Es kann nicht immer gelingen einvernehmlich einen Konsens zu erzielen. Aber selbst wenn dem so ist, so muss am Ende eine Entscheidung gefällt werden. Spätestens wenn es um Querschnittsprozesse geht ist hier die Verwaltungsführung gefragt. Diese muss den Mut aufbringen im Sinne der Gesamtorganisation, auch bei widerstreitenden Interessen eine Entscheidung zu treffen. Das Thema „Entscheidungen“ möchte ich allerdings an anderer Stellen nochmal ausführlich thematisieren, kann aber sagen wie Sie schon zu Beginn des Projektes forcieren, dass am Ende eine konkrete Entscheidung getroffen wird. Formulieren Sie einen konkreten Projektauftrag!

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.