BPMN 2.0 und Prozessmanagement für Projektteams: Leitfaden nach ISO 19510 und eCH-0158

Was ist BPMN 2.0?

BPMN steht für Business Process Model and Notation und ist eine standardisierte Notation, mit der Geschäftsprozesse grafisch dargestellt werden. Die Version 2.0 wurde von der Object Management Group (OMG) entwickelt; die Fassung 2.0.1 ist als ISO/IEC 19510:2013 auch internationale Norm. Ihr erklärtes Ziel ist eine Notation, die alle Beteiligten verstehen: die Business Analysts, die erste Prozessentwürfe erstellen, die Entwickler, die Prozesse technisch umsetzen, und die Fachleute, die Prozesse steuern und überwachen. Die Norm definiert Notation und Semantik von Kollaborations-, Prozess- und Choreographiediagrammen ^[1].

Die Norm umfasst 507 Seiten, wurde 2022 bestätigt und ist bei ISO kostenlos erhältlich ^[1]. Dieser Umfang zeigt ein grundlegendes Merkmal von BPMN: Die Notation bietet sehr viele Symbole und Modellierungsmöglichkeiten, von einfachen Ablaufdiagrammen bis zu ausführbaren Prozessen in Workflow-Systemen. Für die meisten Zwecke in Projekten und Organisationen genügt ein kleiner Teil davon. Wer mit dem vollen Symbolsatz modelliert, erzeugt Diagramme, die nur noch Fachleute lesen können.

Wozu nutzen Projektteams BPMN?

• Ist-Prozesse aufnehmen und verstehen, bevor eine neue Software eingeführt wird.
• Soll-Prozesse entwerfen und mit Fachbereich und Informatik abstimmen.
• Anforderungen herleiten: Jede Aktivität und jede Schnittstelle zu anderen Beteiligten erzeugt Anforderungen.
• Zuständigkeiten klären: Lanes zeigen, welche Rolle welchen Schritt verantwortet.
• Schulung und Einführung: Mitarbeitende sehen, wie der neue Ablauf funktioniert.
• Prozesse automatisieren: Ausführbare Modelle steuern Workflow-Systeme.

In Projekten ist BPMN besonders wertvoll an der Schnittstelle zwischen Fachbereich und Informatik. Ein Prozessdiagramm macht sichtbar, was in Gesprächen oft unausgesprochen bleibt: Wer entscheidet an welcher Stelle, was passiert bei einer Ablehnung, welche Informationen fliessen zu externen Partnern? Der IREB-Lehrplan nennt BPMN ausdrücklich als standardisierte Modellierungssprache für Prozessmodelle, die Geschäftsprozesse oder technische Abläufe beschreiben ^[6]. Wie BPMN-Modelle mit Anforderungen zusammenspielen, beschreibt der Leitfaden Requirements Engineering.

Aus welchen Elementen besteht ein BPMN-Diagramm?

Mit diesen acht Elementen lassen sich die meisten Geschäftsprozesse verständlich darstellen. eCH-0158 beschränkt sich auf der deskriptiven Ebene genau auf einen solchen reduzierten Satz und beschreibt für jedes Element Ausprägungen, Namenskonventionen, Attribute und Modellierungsregeln, jeweils mit Beispielen für konforme und nicht konforme Modelle ^[2]. Eine ausführliche Erklärung der Symbole mit Gateway-Logik bietet der Beitrag BPMN-Symbole und Gateways.

Welche Modellierungsebenen gibt es?

Die Unterscheidung der drei Ebenen stammt aus dem eCH-Hilfsmittel eCH-0074; eCH-0158 beschränkt sich ausdrücklich auf die deskriptive Ebene. Dort wird etwa auf das auslösende Nachrichten-Zwischenereignis verzichtet, weil aus Geschäftssicht der Versand einer Nachricht immer eine Tätigkeit voraussetzt, die beschrieben wird ^[2]. Für die analytische Modellierung ergänzt eine Beilage zu eCH-0158 eine erweiterte Symbolpalette ^[3]. Für Projektteams heisst das: Beginnen Sie deskriptiv, und erweitern Sie nur dort, wo die Analyse es verlangt.

Welche Modellierungsregeln machen Diagramme lesbar?

Diese Regeln stammen aus eCH-0158 und sind für die Schweizer Verwaltung normativ; für Unternehmen sind sie eine bewährte Stilvorgabe ^[2]. Sie verhindern die häufigsten Probleme in der Praxis: überladene Diagramme, unklare Entscheidungen, offene Enden und uneinheitliche Bezeichnungen. Organisationen, die mehrere Personen modellieren lassen, sollten eine solche Stilvorgabe verbindlich festlegen, sonst entstehen Diagramme, die zwar korrektes BPMN sind, aber unterschiedlich gelesen werden.

Wie läuft Prozessmanagement im Projekt ab?

1. 1Prozess abgrenzen: Start, Ende, Ergebnis und Beteiligte festlegen.
2. 2Ist-Prozess aufnehmen: in Workshops, Interviews oder durch Beobachtung.
3. 3Ist-Prozess analysieren: Schwachstellen, Medienbrüche, Wartezeiten, Doppelarbeit.
4. 4Soll-Prozess gestalten: Verbesserungen, Automatisierung, neue Zuständigkeiten.
5. 5Soll-Prozess abstimmen und freigeben: mit Prozesseigner und Betroffenen.
6. 6Einführen: Schulung, Anpassung von Systemen und Dokumenten.
7. 7Messen und verbessern: Kennzahlen beobachten, Prozess regelmässig überprüfen.

Diese Schritte bilden einen Kreislauf, der nicht mit der Einführung endet. Prozesse verändern sich mit Organisation, Systemen und Rahmenbedingungen; ein Prozessmodell, das nicht gepflegt wird, verliert schnell seinen Wert. Wie die Aufnahme gelingt, beschreibt der Beitrag Prozesse aufnehmen; wie Ist und Soll verglichen werden, der Beitrag Ist-Soll-Analyse.

BPMN, EPK oder Flussdiagramm?

BPMN ist nicht die einzige Notation für Prozesse. Im deutschsprachigen Raum ist die Ereignisgesteuerte Prozesskette (EPK) verbreitet, die Anfang der 1990er-Jahre am Institut für Wirtschaftsinformatik der Universität des Saarlandes entwickelt wurde ^[4]. Sie basiert auf abwechselnden Ereignissen und Funktionen und ist im deutschsprachigen Raum weit verbreitet, unter anderem in ARIS-Umgebungen ^[5]. Einfache Flussdiagramme sind leicht verständlich, bieten aber keine standardisierte Semantik für Zuständigkeiten und Kommunikation. Einen Vergleich mit Entscheidungshilfe bietet der Beitrag BPMN vs. EPK vs. Flussdiagramm.

Wo hilft BPMN in Dienstleistungsunternehmen?

Agenturen, Kanzleien und Treuhandbüros haben wiederkehrende Abläufe, die sich gut mit BPMN darstellen lassen: die Abwicklung eines Kundenauftrags von der Anfrage bis zur Rechnung, die Mandatsannahme mit Konfliktprüfung oder den Monatsabschluss mit Belegerfassung und Freigabe. Gerade in kleinen Organisationen sind solche Abläufe oft nur in den Köpfen einzelner Personen dokumentiert. Ein einfaches BPMN-Diagramm macht sie übertragbar, etwa für Stellvertretungen oder neue Mitarbeitende. Ausgearbeitete Beispiele bietet der Beitrag BPMN-Beispiele aus Agentur, Kanzlei und Treuhand.

Wie werden Prozesse dokumentiert und gepflegt?

Ein Prozessdiagramm allein ist noch keine Prozessdokumentation. eCH-0158 nennt als optionale Attribute eines Diagramms unter anderem Ist- oder Soll-Status, Prozesseigner, Autor, Status mit In Bearbeitung, In Prüfung und Freigegeben, Datum der letzten Bearbeitung, Klassifizierung und Freigabe ^[2]. Ergänzt um Beschreibungen der Aktivitäten, beteiligte Systeme, Dokumente und Kennzahlen entsteht eine Dokumentation, die Schulung, Kontrolle und Verbesserung unterstützt. Wie das in kleinen und mittleren Unternehmen mit vertretbarem Aufwand gelingt, beschreibt der Beitrag Prozessdokumentation für KMU.

Welche Werkzeuge eignen sich für BPMN?

Für BPMN gibt es zahlreiche Werkzeuge, von kostenlosen Online-Editoren bis zu umfassenden Prozessmanagement-Plattformen mit Repository, Freigabeworkflows und Auswertungen. Wichtig sind standardkonforme Symbole, Export im BPMN-XML-Format für den Austausch, gemeinsames Arbeiten und eine Versionsverwaltung. In Organisationen mit vielen Prozessen lohnt sich ein zentrales Repository, in dem Prozesse eindeutig nummeriert, mit Attributen versehen und freigegeben werden. eCH-0158 empfiehlt fortlaufende, unveränderbare Prozessnummern statt hierarchischer Nummerierungen, die bei Umstrukturierungen aufwendig angepasst werden müssen ^[2].

In Flenio lassen sich die Ergebnisse von Prozessprojekten mit Aufgaben, Meilensteinen und Dokumenten verbinden: etwa die Aufnahme als Workshop-Serie planen, Diagramme als Dateien im Projekt ablegen und Verbesserungsmassnahmen als Aufgaben mit Verantwortlichen verfolgen. Für die Moderation von Aufnahme-Workshops bietet flenio.ch eine Checkliste Workshop-Moderation; Zuständigkeiten lassen sich zusätzlich mit einer RACI-Matrix festhalten.

Typische Fehler in der Prozessmodellierung

• Zu viel auf einmal: Diagramme mit dreissig und mehr Aktivitäten, die niemand liest.
• Technische Details auf der fachlichen Ebene: Systemaufrufe statt Arbeitsschritte.
• Unklare Entscheidungen: Gateways ohne vorangehende Prüftätigkeit und ohne beschriftete Ausgänge.
• Offene Enden: Zweige, die nirgends hinführen.
• Uneinheitliche Bezeichnungen: «Rechnung prüfen» hier, «Faktura kontrollieren» dort.
• Modelle ohne Eigner: Niemand fühlt sich für die Aktualität verantwortlich.

BPMN in der Schweizer Verwaltung

In der Schweiz gilt BPMN gemäss eCH-0140 als Standard für die grafische Darstellung von Geschäftsprozessen der öffentlichen Verwaltung; eCH-0158 vereinheitlicht die Anwendung und richtet sich an Prozessverantwortliche, Prozessmanager und Unternehmensarchitekten ^[2]. Wer Aufträge für Bund, Kantone oder Gemeinden ausführt, wird deshalb häufig nach eCH-0158-konformen Modellen gefragt. Die Konventionen sind aber auch für Unternehmen nützlich, weil sie praxiserprobte Antworten auf die Frage geben, wie viel BPMN genug ist. Die folgenden Beiträge vertiefen Symbole, Beispiele, Aufnahme, Ist-Soll-Analyse, Notationsvergleich und Dokumentation.

Welche Rollen braucht Prozessmanagement?

Prozessmanagement funktioniert nur, wenn Verantwortung klar geregelt ist. Die wichtigste Rolle ist der Prozesseigner: eine Person, die für einen Prozess als Ganzes verantwortlich ist, über Änderungen entscheidet und dafür sorgt, dass die Dokumentation aktuell bleibt. Daneben braucht es Personen, die Prozesse aufnehmen und modellieren können, oft Business Analysts oder Prozessmanagerinnen, sowie die Prozessbeteiligten, die den Ablauf täglich ausführen und genau wissen, wo er hakt. In grösseren Organisationen kommt eine zentrale Stelle hinzu, die Methoden, Werkzeuge und Konventionen vorgibt und die Prozesslandkarte pflegt.

In kleinen und mittleren Unternehmen werden diese Rollen meist von wenigen Personen zusätzlich zu ihren eigentlichen Aufgaben übernommen. Das ist kein Problem, solange klar ist, wer für welchen Prozess verantwortlich ist. Häufig übernimmt die Geschäftsleitung die Eignerschaft für Führungsprozesse, die Bereichsleitungen für Kern- und Unterstützungsprozesse. Wichtig ist, dass Prozesseigner Entscheidungsbefugnis haben: Wer für einen Prozess verantwortlich ist, aber Änderungen nicht durchsetzen kann, bleibt wirkungslos.

Welchen Nutzen bringt Prozessmanagement?

Der Nutzen zeigt sich auf mehreren Ebenen. Kurzfristig schafft ein gemeinsames Prozessbild Klarheit über Zuständigkeiten und Schnittstellen; viele Konflikte zwischen Abteilungen entstehen, weil unklar ist, wer wann was übernimmt. Mittelfristig lassen sich Schwachstellen gezielt beseitigen, etwa Wartezeiten, Doppelarbeit oder Medienbrüche, was Durchlaufzeiten verkürzt und Kosten senkt. Langfristig wird die Organisation unabhängiger von einzelnen Personen und kann neue Mitarbeitende schneller einarbeiten, Software gezielter auswählen und Veränderungen kontrollierter umsetzen.

Für Projekte ist Prozessmanagement besonders bei der Einführung neuer Software entscheidend. Wer vor der Auswahl die wichtigsten Prozesse kennt, kann Anbieter gezielt danach fragen, wie ihre Lösung diese Abläufe unterstützt, und vermeidet, dass sich die Organisation an eine Software anpasst, statt die Software an die Organisation. Ein Ist-Soll-Vergleich zeigt zudem, welche Verbesserungen von der neuen Lösung erwartet werden, und liefert Kennzahlen, an denen der Erfolg des Projekts später gemessen werden kann.

Wie gelingt der Einstieg in BPMN?

1. 1Eine Stilvorgabe festlegen, etwa eCH-0158 oder eine eigene Kurzfassung mit den erlaubten Symbolen.
2. 2Mit einem überschaubaren, häufigen Prozess beginnen, der allen bekannt ist.
3. 3Den Prozess in einem Workshop mit Karten aufnehmen und danach in BPMN übertragen.
4. 4Das Diagramm mit den Beteiligten an einem konkreten Fall validieren.
5. 5Erfahrungen auswerten und die Stilvorgabe bei Bedarf ergänzen.
6. 6Weitere Prozesse schrittweise aufnehmen und in einer Prozesslandkarte ordnen.

Ein häufiger Fehler beim Einstieg ist der Versuch, BPMN vollständig zu lernen, bevor das erste Diagramm entsteht. Für deskriptive Modelle genügen wenige Elemente, die sich in einer Stunde erklären lassen. Erst wenn die Analyse oder die Automatisierung es verlangt, lohnt sich die Beschäftigung mit erweiterten Symbolen. Ebenso wichtig ist, dass alle Modellierenden dieselben Konventionen anwenden; sonst entstehen Diagramme, die zwar korrekt, aber nicht vergleichbar sind.

Von der Modellierung zur Automatisierung

BPMN-Modelle können bis zur Ausführung in einer Workflow-Engine verfeinert werden. Dafür werden Aktivitäten als Benutzer-, Service- oder Skriptaufgaben typisiert, Daten und Bedingungen technisch beschrieben und Schnittstellen zu anderen Systemen festgelegt. Dieser Schritt gehört zur ausführbaren Ebene und verlangt technisches Wissen. Für die meisten Organisationen ist es sinnvoll, zuerst die deskriptive Ebene sauber zu beherrschen und nur ausgewählte, stark standardisierte Prozesse zu automatisieren, etwa Freigaben, Genehmigungen oder wiederkehrende Abläufe mit vielen Fällen.

Die Trennung der Ebenen schützt dabei vor einem verbreiteten Problem: Wenn fachliche Diagramme mit technischen Details überladen werden, verlieren sie ihre Verständlichkeit für die Fachseite. Besser ist es, das fachliche Modell als Grundlage zu behalten und das ausführbare Modell als eigene Verfeinerung zu führen, die mit dem fachlichen Modell abgestimmt bleibt.

Wie wird der Erfolg von Prozessen gemessen?

Prozesse werden mit wenigen, aussagekräftigen Kennzahlen gesteuert. Bewährt sind die Durchlaufzeit vom Auslöser bis zum Ergebnis, die tatsächliche Bearbeitungszeit, die Zahl der Fälle pro Zeitraum, die Quote der Fälle mit Korrekturschleifen und die Fehlerquote. Aus Durchlauf- und Bearbeitungszeit ergibt sich die Wartezeit, die in vielen Prozessen den grössten Teil der Durchlaufzeit ausmacht. Wer diese Werte vor einer Veränderung erhebt und danach erneut misst, kann den Nutzen von Prozessverbesserungen belegen, statt ihn nur zu behaupten.

Kennzahlen sollten dabei dem Prozesseigner dienen, nicht der Kontrolle einzelner Mitarbeitender. Werden Prozesskennzahlen zur Leistungsbewertung von Personen genutzt, sinkt die Bereitschaft, Probleme offen anzusprechen, und die Zahlen verlieren ihre Aussagekraft. Hilfreich ist, Kennzahlen regelmässig gemeinsam mit den Beteiligten zu besprechen, etwa vierteljährlich, und daraus konkrete Verbesserungen abzuleiten. Ein ausgearbeitetes Rechenbeispiel zur Durchlaufzeit enthält der Beitrag zur Ist-Soll-Analyse.

Prozessmanagement als Projekt oder als Daueraufgabe?

Viele Organisationen starten Prozessmanagement als Projekt: Prozesse werden aufgenommen, verbessert und dokumentiert, danach endet das Projekt. Das ist ein guter Anfang, aber kein Endzustand. Prozesse verändern sich mit neuen Kunden, Mitarbeitenden, Systemen und Vorschriften; ohne laufende Pflege veralten Modelle innerhalb weniger Monate. Nachhaltig wird Prozessmanagement, wenn es nach dem Startprojekt als Daueraufgabe verankert ist: mit Prozesseignern, regelmässigen Überprüfungen und einem einfachen Verfahren, über das Mitarbeitende Verbesserungsvorschläge einbringen können.

Für Projektteams bedeutet das: Wer in einem Projekt Prozesse aufnimmt oder verändert, sollte von Anfang an klären, wer die Ergebnisse nach Projektende pflegt. Die Übergabe an die Prozesseigner gehört in den Projektabschluss, ebenso wie die Ablage der Modelle an einem zentralen Ort. So entsteht aus einem einmaligen Projekt ein dauerhafter Nutzen für die Organisation.

Prozessmanagement, Projektmanagement und Requirements Engineering

Prozessmanagement, Projektmanagement und Requirements Engineering greifen in vielen Vorhaben ineinander. Ein Projekt zur Einführung einer neuen Software beginnt oft mit der Aufnahme und Analyse der betroffenen Prozesse, leitet daraus Anforderungen ab, wählt eine Lösung aus und führt sie zusammen mit dem Soll-Prozess ein. Das Projektmanagement steuert Umfang, Termine, Kosten und Risiken; das Requirements Engineering übersetzt Prozessschritte in prüfbare Anforderungen; das Prozessmanagement sorgt dafür, dass die neue Arbeitsweise nach Projektende gelebt und gepflegt wird.

Wer diese drei Disziplinen verbindet, vermeidet typische Brüche: Anforderungen, die an den tatsächlichen Abläufen vorbeigehen, Software, die eingeführt, aber nicht genutzt wird, und Prozessmodelle, die nach dem Projekt niemand mehr anschaut. Die Leitfäden zu Projektplanung und Requirements Engineering auf flenio.ch vertiefen die jeweils anderen Perspektiven und verweisen an den passenden Stellen auf die Prozessmodellierung.

Für den Einstieg empfiehlt sich, mit einem einzigen, gut abgegrenzten Prozess zu beginnen, ihn nach den Regeln von eCH-0158 zu modellieren, mit den Beteiligten zu validieren und erst dann weitere Prozesse anzugehen. Die Erfahrungen aus diesem ersten Prozess fliessen in die eigene Stilvorgabe ein. Alle Beiträge dieses Leitfadens nennen ihre Quellen mit Abrufdatum und werden jährlich fachlich überprüft; massgebend bleiben die Originaltexte von ISO/IEC 19510 und eCH-0158.

Wer tiefer einsteigen möchte, findet in den folgenden Beiträgen Symbole, Beispiele, Methoden der Aufnahme, Ist-Soll-Analyse, Notationsvergleich und Dokumentation mit durchgängigen Praxisbeispielen aus Agentur, Kanzlei und Treuhand. Jeder Beitrag lässt sich auch einzeln lesen und verweist an den passenden Stellen auf die übrigen Themen des Leitfadens.