6.2.4 Prozessmodelle
Artikel Methoden und Techniken
Prozessmodelle sind vereinfachte Abbildungen von Prozessen einer Organisation. Sie stellen die chronologisch-sachlogische Abfolge von Funktionen beziehungsweise Tätigkeiten dar. Prozessmodelle können, je nach Zielstellung, in unterschiedlichem Detaillierungsgrad und Umfang modelliert werden. Aufgrund der Komplexität können meist nicht alle zu betrachtenden Prozesse in einem Prozessmodell dargestellt werden. Daher werden unterschiedliche Prozessmodelle über verschiedene Hierarchie- oder Beschreibungsebenen (Level) hinweg abgebildet. Dabei wird mit einer Übersichtsdarstellung auf Ebene der Hauptaufgaben begonnen, die dann schrittweise durch Detailmodelle auf Teilaufgabenebene verfeinert wird. Die Anzahl der Beschreibungsebenen (Level) ist dabei vom gewünschten Detaillierungsgrad abhängig. Auf jeder Beschreibungsebene kann dabei – abhängig von der Zielstellung – ein unterschiedlicher Prozessmodelltyp verwendet werden. Mit Hilfe von Prozessmodellen können vorhandene Abläufe anschaulich und eindeutig dokumentiert werden. Sie können während eines Organisationsprojektes, aber auch während der alltäglichen Arbeit in einer Organisation für verschiedene Zwecke genutzt werden:
- Prozessmodelle als standardisierte Dokumentationsform für Abläufe sind Voraussetzung für eine Zertifizierung nach DIN EN ISO 9001:2008.
- Prozessmodelle können weiterhin der Vermittlung von Verständnis über Tätigkeiten, Funktionen, Rollen und Schnittstellen dienen und somit zur Erhöhung der Transparenz von Abläufen innerhalb und außerhalb der Organisation beitragen. Damit wird die Verfahrenssicherheit erhöht, was wiederum einen Beitrag zur Risikominimierung und Korruptionsprävention leistet.
- Durch die Modellierung von Prozessen wird eine Basis für weiterführende Aktionen wie Schwachstellenanalysen oder Optimierung organisatorischer Abläufe einschließlich Risikominimierung geschaffen.
- Unter Zuhilfenahme spezieller Software sind Prozessmodelle die Grundlage für Simulationen von Veränderungen.
- Prozessmodelle dienen als Grundlage für die Entwicklung von Anwendungen, die Einführung von Workflow-Management-Systemen oder elektronischen Vorgangsbearbeitungssystemen.
Sie können für die Schulung von Nutzern neuer Systeme dienen. Um die allgemeine Verständlichkeit und Einheitlichkeit der Prozessmodelle zu gewährleisten, ist zur Modellierung eine standardisierte Beschreibungssprache in Form von Symbolen (Notation) einzusetzen. Die folgenden Symbole werden häufig verwendet:
Tabelle mit einem Beispiel der Symbole für die Prozessmodellierung, Teil 2 (Vergrößerung öffnet sich im neuen Fenster)
Symbole für die Prozessmodellierung
Je nach verwendeter Software können die Symbole variieren. In Abhängigkeit zum Modellierungsziel und dem sich daraus ableitenden Detaillierungsgrad, ist eines der im Folgenden beschriebenen Modelle zu verwenden.
6.2.4.1 Prozesslandkarten
In einer Prozesslandkarte, auch Prozessarchitekturmodell genannt, werden sämtliche Prozesse einer Organisation inklusive deren Schnittstellen nach außen dargestellt, abgegrenzt und die Abhängigkeiten zwischen den Prozessen auf hoher Abstraktionsebene im Gesamtüberblick aufgezeigt. Die Prozesslandkarte ist somit eine übergeordnete Sicht (Metaebene) auf die Prozesse der Organisation. Die Prozesslandkarte findet Verwendung, wenn eine Übersicht über die Ablauforganisation erarbeitet und dokumentiert werden soll. Auf Basis dieser prozessbezogenen Übersicht kann der Untersuchungsbereich einer Organisationsuntersuchung besser abgegrenzt, Schnittstellen ermittelt und Zusammenhänge und Wechselwirkungen zwischen einzelnen Prozessen analysiert werden.
Die Erstellung einer Prozesslandkarte erfordert einen Überblick über sämtliche Prozesse der Organisation, ohne diese detailliert zu analysieren. Benötigte Informationen können mittels Dokumentenanalyse (QM-Dokumentation, Produktkatalog, Geschäftsverteilungsplan,…) oder durch Interviews beschafft werden. Bei der Modellierung einer Prozesslandkarte wird entweder die oben dargestellte Notation verwendet, oder die Prozesslandkarte wird mit Hilfe von Blockpfeilen dargestellt. Beide Darstellungsalternativen sind in der Praxis üblich:
Prozesslandkarte
Bei der Erstellung von Prozesslandkarten sind einige Regeln zu beachten:
- An der Schnittstelle müssen die übergehenden Informationsobjekte (Papierantrag, Datensatz,…) dargestellt werden.
- Externe Prozessschnittstellen (Lieferanten, Kunden) sind ebenfalls zu erfassen.
6.2.4.2 Flussdiagramme
Das Flussdiagramm, auch Flow Chart genannt, bildet einen einzelnen Prozess ab. Dabei wird der Schwerpunkt auf die beteiligten Rollen/Organisationseinheiten gelegt. Das Flussdiagramm dient somit der übersichtsartigen Darstellung einzelner, mehrere Organisationseinheiten umfassende Prozesse. Auf Basis der eher groben Flussdiagramme kann so ein organisationsweites Verständnis über Verlauf und Beteiligte an einem Prozess gewonnen werden. Das Flussdiagramm dient weiterhin als Grundlage zur Identifizierung und weiteren Analyse von Teilprozessen.
Grafik: Beispiel Flussdiagramm Antragsbearbeitung (Vergrößerung öffnet sich im neuen Fenster)
Flussdiagramm Antragsbearbeitung - Beispiel
Bei der Erstellung eines Flussdiagramms sollten die oben angegebenen Symbole benutzt und folgende Regeln befolgt werden:
- Die beteiligten Organisationseinheiten sind in entsprechenden Spalten (so genannte Schwimmbahnen oder swimlanes) darzustellen.
- Es muss ein Informationsobjekt zu Prozessbeginn (Input) und ebenfalls am Ende (Output, Ergebnis) vorliegen.
- Nach jeder Funktion/Tätigkeit folgt ein Informationsobjekt, welches das Ergebnis der Funktion darstellt.
- Eine Funktion kann durch einen Teilprozess ersetzt werden.
- Die Verbindung komplexer Prozesse, welche sich über mehrere Seiten erstrecken, erfolgt über Sprungmarken.
6.2.4.3 Wertschöpfungskettendiagramme (WKD)
Ein Wertschöpfungskettendiagramm (WKD) ist ein Modell zur Darstellung von Geschäftsprozessen. Es findet hauptsächlich – wie auch die Prozesslandkarte auf hohem Abstraktionsniveau Anwendung und dient grundsätzlich zur Strukturierung der wesentlichen Funktionen, Aufgaben, Prozesse einer Organisation. Es stellt die Einstiegsebene für die Geschäftsprozessmodellierung dar. Auf der obersten Ebene werden die Prozesse als Hauptprozesse dargestellt. Die Hauptprozesse gliedern sich in Führungs-, Kern-, und Unterstützungsprozesse.
6.2.4.4 Erweiterte Ereignisgesteuerte Prozessketten (eEPK)
Bei erweiterten Ereignisgesteuerten Prozessketten handelt es sich um eine semiformale Modellierungssprache[1]. Sie beschreibt Arbeitsprozesse als eine Aufeinanderfolge von Funktionen und Ereignissen. Als Ereignis wird dabei ein eingetretener relevanter Zustand bezeichnet. Die Erweiterung erfolgt durch das Hinzufügen von Organisationseinheiten, Informationsobjekten und anderen Zusatzinformationen.
Erweiterte Ereignisgesteuerte Prozessketten werden eingesetzt, wenn verschiedene Sichten (Daten-, Organisations-, Funktions- und Steuerungssicht) auf Prozesse detailliert dargestellt werden sollen. Sie eignen sich gut als Basis für die Erstellung von Software oder Einführung von Standardsoftware. Werden eEPK mit Hilfe von entsprechender Software erzeugt, eignen sich eEPK gut zur Simulation und damit zur Prüfung von Soll-Konzepten.
Grafik: Erweiterte Ereignisgesteuerte Prozesskette – Beispiel (Vergrößerung öffnet sich im neuen Fenster)
Erweiterte Ereignisgesteuerte Prozesskette – Beispiel
Bei der Modellierung Erweiterter Ereignisgesteuerter Prozessketten sind folgende Modellierungsregeln und Konventionen zu beachten:
- Die Darstellung des Prozesses gliedert sich in die drei Bereiche Organisationseinheiten, Ereignisse und Funktionen, Informationsobjekte (siehe Beispiel).
- Der Prozess beginnt und endet immer mit einem Ereignis.
- Ereignisse und Funktionen befinden sich in einer streng alternierenden Reihenfolge, das heißt, auf ein Ereignis folgt immer eine Funktion und auf die Funktion wiederum ein Ereignis.
- Ereignisse und Funktionen haben immer nur jeweils eine eingehende und eine ausgehende Kante (Flusslinie).
- Anstelle einer Funktion kann auch ein Teilprozess stehen.
- Organisationseinheiten werden immer mit Funktionen verbunden, nicht mit Ereignissen.
- Handelt es sich bei einer Verzweigung um eine Alternativenauswahl (oder, exklusiv-oder), muss sie auf eine Funktion folgen, die die Auswahl vornimmt.
- Einer Und-Verzweigung kann auch ein Ereignis voran stehen. Da alle Zweige durchlaufen werden müssen (Parallelarbeit), kann vor einer Und-Verzweigung keine Auswahlentscheidung stehen.
- Bei der Zusammenführung von Verzweigungen ist der gleiche Verknüpfungsoperator zu nutzen, wie bei der Verzweigung.
- Die Bezeichnung einer Funktion erfolgt durch "Substantiv + Verb im Infinitiv", beispielsweise "Vollständigkeit prüfen".
- Die Bezeichnung eines Ereignisses erfolgt durch "Substantiv + Partizip", beispielsweise "Vollständigkeit geprüft".
6.2.4.5 Prozesstabellen
Häufig ist es nicht möglich, alle relevanten Informationen zu einem Prozess in einem graphischen Prozessmodell abzubilden. Zusätzlich zum Modell kann der Prozess dann mit Hilfe einer Prozesstabelle vollständig beschrieben werden. Eine Prozesstabelle kann die folgenden Informationen enthalten:
| Nummer | Funktion/Tätigkeit | Ausführender/Rolle | Beschreibung | Ergebnis | Anmerkung |
|---|---|---|---|---|---|
| 1 | … | ||||
| 2 | Post befördern | Bote/Botin | Post auf Wagen sortieren, eingehende Post verteilen, ausgehende Post einsammeln | Eingangspost verteilt, Ausgangspost eingesammelt | drei Botengänge pro Tag |
| 3 | … |
Beispiel Prozesstabelle
Jede Zeile einer Prozesstabelle wird durch eine laufende Nummer angeführt, die der Nummer der Funktion im Prozessmodell entsprechen muss. Ebenso sind die Bezeichnungen der Funktionen/Tätigkeiten mit denen im Prozessmodell konsistent zu halten.
Eine vollständige Prozessdokumentation sollte folgende Informationen enthalten:
- Zweck des Prozesses, Prozessbesitzer, Prozessabgrenzungen, Prozessverantwortliche und deren Zuständigkeiten, Kunden des Prozesses, Beschreibung des Prozesses, geltende Vorschriften, Vorgaben oder Verfahrensanweisungen, Dokumentationshinweise, Angaben zum Änderungsdienst, administrative Hinweise (Dateinamen, Zugriffsberechtigung, Änderungsberechtigung).
Fußnote
[1] Entwickelt wurde sie von Prof. Dr. August Wilhelm Scheer an der Universität des Saarlandes.
