BPMN vs. Flussdiagramme: Wann und warum Anfänger BPMN verwenden sollten

Flussdiagramme und BPMN-Diagramme zeigen beide, wie die Arbeit von einem Schritt zum nächsten fortschreitet. Der Unterschied liegt hauptsächlich inZweck und Präzision:

Ein Flussdiagramm ist ein universelles Diagramm zur Darstellung von Logik, Schritten und Entscheidungen.
BPMN oder Business Process Model and Notation ist eine standardisierte Sprache, die speziell für die Modellierung von Geschäftsprozessen, Verantwortlichkeiten, Ereignissen, Nachrichten, Daten und Automatisierung entwickelt wurde.

Ein Flussdiagramm ist oft der schnellste Weg, ein einfaches Verfahren zu erklären. BPMN wird nützlicher, wenn ein Prozess mehrere Personen, Abteilungen, Organisationen, Ausnahmen, Fristen oder Softwaresysteme umfasst.

BPMN wird vom Object Management Group als formale Spezifikation verwaltet. Die Notation ist so gestaltet, dass sie für Geschäftsinteressenten verständlich ist, aber dennoch präzise genug, um die technische Umsetzung zu unterstützen. Die aktuell häufig verwendete formale Spezifikation ist BPMN 2.0.2.

1. Was ist ein Flussdiagramm?

Ein Flussdiagramm ist eine visuelle Darstellung einer Abfolge von Schritten. Es verwendet einfache Formen, die durch Pfeile verbunden sind, um zu zeigen, wie eine Aufgabe oder Entscheidung fortschreitet.

Ein typisches Flussdiagramm umfasst:

Oval: Start oder Ende
Rechteck: Prozess oder Aktivität
Raute: Entscheidung
Pfeil: Flussrichtung
Parallelogramm: Eingabe oder Ausgabe
Dokumentenform: Dokument oder Bericht

Zum Beispiel könnte ein einfaches Flussdiagramm zur Erstattung von Ausgaben so aussehen:

Start
  ↓
Mitarbeiter reicht Ausgabenbericht ein
  ↓
Manager prüft Bericht
  ↓
Wird er genehmigt?
 ├── Nein → Bericht an Mitarbeiter zurückgeben
 └── Ja → Finanzabteilung zahlt aus
  ↓
Ende

Flussdiagramme sind einfach zu erstellen und zu verstehen, da sie eine geringe Anzahl bekannter Symbole verwenden. Sie sind nützlich für:

Erklärung eines einfachen Verfahrens
Dokumentation eines Algorithmus
Beschreibung von Fehlerbehebungsschritten
Erfassung eines persönlichen oder abteilungsinternen Arbeitsablaufs
Schulung von Mitarbeitern
Darstellung einer grundlegenden Entscheidungssequenz

Die Hauptbeschränkung besteht darin, dass traditionelle Flussdiagramme nicht immer klar darstellen, wer jede Aufgabe ausführt, wie verschiedene Organisationen kommunizieren, oder was passiert, wenn Ereignisse den normalen Prozess unterbrechen.

2. Was ist BPMN?

BPMN steht für Business Process Model and Notation. Es ist eine standardisierte Notation zur konsistenten Beschreibung von Geschäftsprozessen.

BPMN-Diagramme können darstellen:

Aktivitäten und Aufgaben
Start-, Zwischen- und Endereignisse
Entscheidungen und Verzweigungslogik
Parallele Arbeit
Teilnehmer und Verantwortlichkeiten
Kommunikation zwischen Abteilungen oder Organisationen
Nachrichten
Dateneingaben und -ausgaben
Zeitgeber, Fehler, Stornierungen und Eskalationen
Wiederverwendbare Teilprozesse
Menschliche und automatisierte Aktivitäten

BPMN basiert auf Flussdiagramm-Konzepten, fügt jedoch ein deutlich reichhaltigeres Vokabular für Geschäftsabläufe hinzu. Zu den Kernkategorien gehören Flussobjekte, Verbindungsobjekte, Schwimmbahnen und Artefakte.

Ein vereinfachter BPMN-Prozess könnte wie folgt beschrieben werden:

Kunde reicht Bestellung ein
        ↓
Vertriebssystem erfasst Bestellung
        ↓
Lager prüft Lagerbestand
        ↓
Ist der Artikel verfügbar?
 ├── Nein → Kunde benachrichtigen
 └── Ja → Bestellung kommissionieren und verpacken
                 ↓
           Versanddienstleister liefert Bestellung aus

In einem echten BPMN-Diagramm könnte jeder Teilnehmer in einer separaten Pool- oder Laufzeile erscheinen, und die Kommunikation zwischen ihnen könnte durch Nachrichtenflüsse dargestellt werden.

3. BPMN im Vergleich zu Flussdiagrammen auf einen Blick

Merkmal	Flussdiagramm	BPMN
Hauptzweck	Allgemeine Logik oder Sequenz darstellen	Geschäftsprozesse modellieren
Standardisierung	Oft informell oder werkzeugspezifisch	Formale internationale Modellierungssprache
Lernkurve	Gering	Mittel
Anzahl der Symbole	Kleine Menge	Größeres, spezialisiertes Vokabular
Rollen und Verantwortlichkeiten	Normalerweise begrenzt	Explizit durch Pools und Laufzeilen dargestellt
Organisationsübergreifende Kommunikation	Schwer präzise darzustellen	Durch Nachrichtenflüsse dargestellt
Ausnahmen und Unterbrechungen	Normalerweise vereinfacht	Ereignisse können Timer, Fehler, Nachrichten und Eskalationen darstellen
Parallele Aktivitäten	Möglich, aber oft unklar	Unterstützt durch parallele Gateways
Automatisierungsunterstützung	Begrenzt	Kann detailliert genug sein, um die Implementierung zu unterstützen
Beste Anwendung	Einfache Verfahren und Logik	Komplexe, kollaborative, wiederholbare Prozesse
Typisches Publikum	Allgemeine Benutzer, Studenten, Teams	Analysten, Prozessinhaber, Entwickler, Manager
Detailgrad	Niedrig bis mittel	Mittel bis sehr hoch

4. Der zentrale Unterschied: Allgemeine Logik vs. Geschäftsprozesssemantik

Der wichtigste Unterschied besteht darin, dass ein Flussdiagramm primär Folgendes beantwortet:

„Was passiert als Nächstes?”

BPMN kann mehrere zusätzliche Fragen beantworten:

Wer führt jede Aktivität aus?
Welche Abteilung oder Organisation ist beteiligt?
Ist die Interaktion intern oder extern?
Wird der nächste Schritt durch eine Nachricht, einen Timer, einen Fehler oder eine Bedingung ausgelöst?
Können Aktivitäten parallel stattfinden?
Welche Daten werden benötigt?
Was passiert, wenn der Prozess fehlschlägt?
Welche Aufgaben werden von Menschen, Systemen oder Regeln ausgeführt?
Kann dieser Prozess automatisiert oder überwacht werden?

Ein Flussdiagramm könnte beispielsweise Folgendes besagen:

Antrag prüfen → Antrag genehmigen → Bestätigung senden

Ein BPMN-Modell könnte unterscheiden:

Der Kunde reicht den Antrag ein.
Das Kundenservice-Team validiert ihn.
Ein automatisiertes System prüft Kreditinformationen.
Ein Manager genehmigt Anträge über einem bestimmten Betrag.
Ein Timer löst nach drei Werktagen eine Erinnerung aus.
Eine Nachricht wird an den Kunden gesendet.
Ein Fehlerpfad behandelt fehlende Dokumentation.

Das Flussdiagramm vermittelt den Überblick. BPMN vermittelt die operative Struktur.

5. Die wichtigsten BPMN-Elemente, die Anfänger benötigen

BPMN enthält viele Symbole, aber Anfänger benötigen zunächst nur einen kleinen Kernbestand.

Ereignisse

Ereignisse stellen dar, dass etwas geschieht, anstatt dass jemand etwas tut.

Sie werden als Kreise gezeichnet.

Häufige Typen umfassen:

Startereignis: Beginnt einen Prozess
Zwischeneignis: Tritt während eines Prozesses auf
Endereignis: Schließt einen Prozess ab
Nachrichteneignis: Eine Nachricht wird empfangen oder gesendet
Timer-Ereignis: Eine Frist oder ein geplanter Zeitpunkt ist beteiligt
Fehlerereignis: Ein Fehler tritt auf
Eskalationsereignis: Eine Angelegenheit erfordert Aufmerksamkeit auf höherer Ebene

Beispiele:

Ein Kunde gibt eine Bestellung auf.
Eine Zahlungsfrist läuft ab.
Eine E-Mail wird empfangen.
Ein Systemfehler tritt auf.

Aktivitäten

Aktivitäten stellen durchgeführte Arbeiten dar. Sie werden als abgerundete Rechtecke gezeichnet.

Sie können sein:

Aufgaben:Einzelne Arbeitseinheiten
Teilprozesse:Gruppen zusammenhängender Aktivitäten
Benutzeraufgaben:Arbeit, die von einer Person über ein System erledigt wird
Dienstleistungsaufgaben:Arbeit, die automatisch von Software ausgeführt wird
Manuelle Aufgaben:Arbeit, die ohne Systemunterstützung ausgeführt wird
Geschäftsregel-Aufgaben:Arbeit, die durch eine Geschäftsregel oder einen Entscheidungsdienst bestimmt wird

Für einen Anfänger ist die wichtigste Idee einfach:

Ereignisse treten ein; Aktivitäten werden ausgeführt.

Gateways

Gateways steuern, wie der Prozess aufgeteilt oder zusammengeführt wird. Sie werden als Rauten gezeichnet.

Häufige Gateway-Typen umfassen:

Exklusives Gateway:Nur ein Pfad wird ausgewählt
Paralleles Gateway:Mehrere Pfade finden gleichzeitig statt
Inklusives Gateway:Ein oder mehrere Pfade können ausgewählt werden
Ereignisbasiertes Gateway:Der nächste Pfad hängt davon ab, welches Ereignis zuerst eintritt

Beispiel für eine exklusive Entscheidung:

Zahlung eingegangen?
 ├── Ja → Bestellung versenden
 └── Nein → Zahlungserinnerung senden

Beispiel für parallele Arbeit:

Bestellung genehmigt
      ↓
 ┌───────────────┬────────────────┐
 │               │                │
Bestellung verpacken   Rechnung erstellen   Kunde benachrichtigen
 │               │                │
 └───────────────┴────────────────┘
      ↓
Bestellung versandfertig

Sequenzfluss

Ein durchgezogener Pfeil zeigt die Reihenfolge an, in der Aktivitäten, Ereignisse und Gateways innerhalb desselben Prozesses auftreten.

Aufgabe A → Aufgabe B → Aufgabe C

Nachrichtenfluss

Ein gestrichelter Pfeil stellt die Kommunikation zwischen separaten Teilnehmern oder Pools dar.

Zum Beispiel:

Kunde ──Nachricht──> Unternehmen
Unternehmen ──Bestätigung──> Kunde

Ein Nachrichtenfluss unterscheidet sich vom Sequenzfluss:

Sequenzfluss:Zeigt die Reihenfolge der Arbeit innerhalb eines Prozesses an
Nachrichtenfluss:Zeigt die Kommunikation zwischen Teilnehmern an

Pools und Bahnen

Schwimmbahnen organisieren die Arbeit nach Teilnehmer oder Verantwortungsbereich.

Eine Pool stellt allgemein einen Teilnehmer, eine Organisation, eine Geschäftseinheit oder einen unabhängigen Prozess dar.
Eine Bahn teilt einen Pool in Rollen, Teams, Abteilungen oder Systeme auf.

Beispiel:

Kundenbahn:     Bestellung einreichen ─────────────── Bestätigung erhalten
                         │                              ↑
Vertriebsbahn:        Bestellung prüfen ─────── Bestätigung senden

Pools und Bahnen beantworten eine der wichtigsten Prozessfragen:

Wer ist für diesen Schritt verantwortlich?

Datenobjekte und Anmerkungen

Datenobjekte zeigen Informationen an, die von einer Aktivität verwendet oder erzeugt werden.

Beispiele:

Antragsformular
Rechnung
Vertrag
Kundenakte
Versandetikett

Anmerkungen fügen erläuternden Text hinzu, ohne die Prozesslogik zu ändern.

6. Wann ein Flussdiagramm die bessere Wahl ist

Verwenden Sie ein Flussdiagramm, wenn der Prozess einfach, linear ist oder hauptsächlich Entscheidungen betrifft.

Ein Flussdiagramm ist in der Regel ausreichend, wenn:

Es gibt nur einen Hauptteilnehmer
Der Prozess hat nur wenige Schritte
Verantwortlichkeiten müssen nicht hervorgehoben werden
Es gibt keine komplexen Interaktionen mit externen Parteien
Das Diagramm dient einer schnellen Erklärung
Der Prozess wird informell untersucht
Sie dokumentieren einen Algorithmus oder eine Fehlerbehebungsroutine
Ihr Publikum ist mit BPMN nicht vertraut

Zum Beispiel kann „Wie man ein Passwort zurücksetzt“ besser durch ein einfaches Flussdiagramm dargestellt werden:

Start
  ↓
Benutzername eingeben
  ↓
Konto gefunden?
 ├── Nein → Fehler anzeigen
 └── Ja → Reset-E-Mail senden
                ↓
          Benutzer erstellt Passwort
                ↓
               Ende

Die Verwendung von BPMN für diesen Prozess könnte unnötige Komplexität hinzufügen, es sei denn, der Zweck besteht darin, den gesamten Servicebetrieb zu modellieren, einschließlich Identitätsüberprüfung, Benachrichtigungen, Systemaufgaben, Eskalation und Audit-Protokolle.

7. Wann BPMN die bessere Wahl ist

Verwenden Sie BPMN, wenn Sie einen echten Geschäftsprozess modellieren müssen, anstatt lediglich eine Sequenz zu beschreiben.

BPMN ist besonders nützlich, wenn ein Prozess Folgendes aufweist:

Mehrere Abteilungen
Mehrere Rollen oder Teilnehmer
Kunden, Lieferanten, Aufsichtsbehörden oder Partner
Übergaben zwischen Teams
Parallele Aktivitäten
Externe Nachrichten
Zeitgeber oder Fristen
Fehlerbehandlung oder Ausnahmebehandlung
Genehmigungsebenen
Automatisierte Systemaufgaben
Compliance-Anforderungen
Wiederholte Bemühungen zur Prozessverbesserung
Ein zukünftiges Ziel der Workflow-Automatisierung

Typische BPMN-Anwendungsfälle umfassen:

Genehmigung von Bestellungen
Bearbeitung von Kreditanträgen
Versicherungsansprüche
Einarbeitung von Mitarbeitern
Eskalation im Kundensupport
Rechnungsabwicklung
Produktretouren
Überweisungen im Gesundheitswesen
Vertragsprüfung
Lieferungserfüllung
Regulatorische Berichterstattung
Workflows für Software-Bereitstellungen

Eine nützliche Regel lautet:

Wenn ein Prozess eine Grenze überschreitet – zwischen Personen, Teams, Systemen oder Organisationen –, ist BPMN in der Regel eine Überlegung wert.

8. Warum BPMN verwenden?

Eine gemeinsame Sprache

Verschiedene Gruppen beschreiben denselben Prozess oft unterschiedlich. Ein Geschäftsmanager spricht möglicherweise über Genehmigungen, ein Entwickler über Dienste und ein Mitarbeiter über tägliche Aufgaben.

BPMN bietet eine gemeinsame visuelle Sprache, die diesen Gruppen helfen kann, denselben Prozess zu diskutieren. Sein Designziel ist es, für Geschäftsinteressengruppen nutzbar zu sein und gleichzeitig präzise genug zu sein, um in Software-Prozesskomponenten übersetzt zu werden.

Klare Verantwortlichkeit

Spalten machen Verantwortlichkeiten sichtbar.

Anstatt Folgendes anzuzeigen:

Antrag prüfen → Antrag genehmigen → Konto erstellen

BPMN kann Folgendes anzeigen:

Kunde reicht Antrag ein
Kundenservice prüft die Informationen
Kreditteam führt eine Bewertung durch
Manager genehmigt die Ausnahme
IT-System erstellt das Konto

Dies kann zu doppelter Arbeit, unklarer Zuständigkeit und unnötigen Übergaben führen.

Bessere Ausnahmeanalyse

Viele reale Prozesse folgen nicht dem optimalen Pfad. BPMN erleichtert die Modellierung:

Fehlende Informationen
Abgelehnte Anträge
Abgelaufene Fristen
Fehlgeschlagene Zahlungen
Systemfehler
Stornierungen
Kundenbeschwerden
Entschädigung oder Korrekturmaßnahme

Ein Flussdiagramm kann Ausnahmen darstellen, aber BPMN bietet spezialisierte Ereignistypen und Konventionen, um diese klarer darzustellen.

Unterstützung für Automatisierung

BPMN-Modelle können genügend Details enthalten, um die Implementierung von Workflows zu steuern. Nicht jedes BPMN-Diagramm ist ausführbar, aber BPMN ist besser geeignet als ein einfaches Flussdiagramm, wenn das Modell später zur Konfiguration oder Gestaltung eines automatisierten Prozesses verwendet werden soll.

Ein Prozessdesigner kann beispielsweise zwischen Folgendem unterscheiden:

Eine von einem Mitarbeiter durchgeführte Aufgabe
Eine von einem automatisierten Dienst durchgeführte Aufgabe
Eine von einer Geschäftsregel bewertete Entscheidung
Eine von einem anderen System empfangene Nachricht
Ein Timer, der eine Aktion auslöst

Verbesserte Prozessverbesserung

Ein BPMN-Diagramm kann helfen, Folgendes zu identifizieren:

Engpässe
Lange Genehmigungswege
Wiederholte Dateneingabe
Überflüssige Überprüfungen
Manuelle Aufgaben, die sich für Automatisierung eignen
Fehlende Ausnahmepfade
Übermäßige Übergaben
Unklare Zuständigkeit
Verzögerungen durch externe Parteien

Dies macht BPMN nicht nur für die Dokumentation von Prozessen wertvoll, sondern auch für deren Analyse und Neugestaltung.

9. Die Nachteile von BPMN

BPMN ist leistungsstark, aber nicht immer die richtige Wahl.

Es hat eine steilere Lernkurve

Flussdiagramme können oft sofort verstanden werden. BPMN erfordert von den Benutzern das Erlernen von Unterscheidungen wie:

Sequenzfluss vs. Nachrichtenfluss
Ereignisse vs. Aktivitäten
Pools vs. Spuren
Exklusive vs. parallele Gateways
Unterbrechende vs. nicht unterbrechende Ereignisse
Erfassende vs. auslösende Ereignisse

Diagramme können unübersichtlich werden

Ein großes BPMN-Diagramm kann Dutzende von Symbolen und sich kreuzende Linien enthalten. Schlecht entworfene Modelle können schwerer zu verstehen sein als ein einfaches Flussdiagramm.

Präzision kann falsches Vertrauen erzeugen

Die Verwendung von BPMN-Symbolen macht ein Prozessmodell nicht automatisch korrekt. Das Modell hängt weiterhin von korrekten Informationen von Prozessinhabern und Fachexperten ab.

Nicht jedes Publikum benötigt die vollständige Details

Führungskräfte möchten möglicherweise eine hochlevelige Prozessübersicht, während ein Workflow-Entwickler detaillierte Aufgaben- und Ausnahmedaten benötigen könnte. Ein Diagramm dient selten beiden Zwecken perfekt.

Es kann übermäßig eingesetzt werden

Ein fünfschrittiges internes Verfahren benötigt nicht zwingend Nachrichtenereignisse, mehrere Pools und verschachtelte Teilprozesse. Die Notation sollte dem Problem entsprechen.

10. Ein praktischer Entscheidungsleitfaden

Verwenden Sie diese Fragen, um zwischen einem Flussdiagramm und BPMN zu wählen:

Wie viele Teilnehmer sind beteiligt?
- Eine Person oder ein Team: Ein Flussdiagramm reicht möglicherweise aus.
- Mehrere Teams oder Organisationen: BPMN ist besser geeignet.
Spielen Verantwortlichkeiten eine Rolle?
- Wenn nein, verwenden Sie ein Flussdiagramm.
- Wenn ja, verwenden Sie Spuren oder Pools in BPMN.
Gibt es externe Kommunikationen?
- Wenn nein, kann entweder die Notation funktionieren.
- Wenn ja, kann BPMN Nachrichten vom internen Prozessfluss unterscheiden.
Gibt es Zeitgeber, Fehler oder Eskalationen?
- Wenn nein, kann ein Flussdiagramm ausreichend sein.
- Wenn ja, bietet BPMN klarere Modellierungswerkzeuge.
Soll der Prozess automatisiert werden?
- Wenn nein, kann ein Flussdiagramm für einen einfachen Prozess angemessen sein.
- Wenn ja, ist BPMN normalerweise eine bessere Grundlage.
Muss der Prozess als formaler Standard wiederverwendet werden?
- Wenn nein, verwenden Sie die einfachste Notation, die Ihr Publikum versteht.
- Wenn ja, bietet BPMN eine größere Konsistenz zwischen Diagrammen und Werkzeugen.
Wie ist das Kompetenzniveau Ihres Publikums?
- Allgemeines Publikum: Beginnen Sie mit einem einfachen Flussdiagramm oder einem BPMN auf hohem Niveau.
- Analysten und technische Teams: Verwenden Sie BPMN mit angemessenem Detailgrad.

11. Eine einsteigerfreundliche BPMN-Modellierungsmethode

Schritt 1: Definieren Sie die Prozessgrenzen

Entscheiden Sie, wo der Prozess beginnt und endet.

Zum Beispiel:

Start: Kunde reicht eine Supportanfrage ein
Ende: Kunde erhält eine Lösung

Vermeiden Sie es, die gesamte Organisation auf einmal zu modellieren.

Schritt 2: Identifizieren Sie die Beteiligten

Listen Sie die beteiligten Personen, Teams, Organisationen und Systeme auf.

Beispiel:

Kunde
Support-Mitarbeiter
Technischer Support
Abrechnungssystem
Service-Manager

Diese können zu Pools oder Spalten werden.

Schritt 3: Schreiben Sie zunächst den Happy Path

Dokumentieren Sie den normalen Prozess ohne Ausnahmen.

Anfrage erhalten
  ↓
Anfrage klassifizieren
  ↓
Problem untersuchen
  ↓
Problem lösen
  ↓
Kunde benachrichtigen
  ↓
Anfrage schließen

Dies bietet Ihnen eine klare Grundlage, bevor Sie Komplexität hinzufügen.

Schritt 4: Start- und Endereignisse hinzufügen

Jeder vollständige BPMN-Prozess sollte einen klaren Anfang und ein klares Ende haben.

Beispiele:

Start: Nachricht eingegangen
Start: Zeitlimit erreicht
Start: Kunde reicht Formular ein
Ende: Fall geschlossen
Ende: Anfrage abgelehnt
Ende: Zahlung abgeschlossen

Schritt 5: Arbeit den Beteiligten zuweisen

Platzieren Sie jede Aktivität in der entsprechenden Spalte.

Zum Beispiel:

Kunde:       Anfrage einreichen ───────────── Lösung erhalten
Support:                    Klassifizieren ─ Untersuchen ─ Lösen
System:                                      Benachrichtigung senden

Schritt 6: Entscheidungsgateways hinzufügen

Verwenden Sie ein exklusives Gateway, wenn nur ein Pfad verfolgt werden soll.

Problem gelöst?
 ├── Nein → Eskalieren
 └── Ja → Kunde benachrichtigen

Verwenden Sie kein Gateway nur, weil eine Aufgabe eine Frage im Namen hat. Verwenden Sie eines, wenn der Prozess tatsächlich verzweigt.

Schritt 7: Parallele Arbeit sorgfältig hinzufügen

Verwenden Sie ein paralleles Gateway, wenn Aktivitäten tatsächlich gleichzeitig stattfinden können.

Zum Beispiel, nachdem eine Bestellung genehmigt wurde:

Lagerbestand reservieren
Rechnung erstellen
Lager benachrichtigen

Wenn eine Aktivität vor einer anderen stattfinden muss, modellieren Sie sie nicht als parallel.

Schritt 8: Nachrichten und Daten hinzufügen

Zeigen Sie Nachrichten an, wenn Teilnehmer kommunizieren.

Beispiele:

Kunde sendet Antrag
Lieferant sendet Versandbenachrichtigung
System sendet Genehmigungs-E-Mail

Fügen Sie Datenobjekte hinzu, wenn Informationen für die Aktivität wichtig sind.

Schritt 9: Ausnahmen hinzufügen

Fragen Sie sich:

Was ist, wenn erforderliche Informationen fehlen?
Was ist, wenn der Kunde nicht antwortet?
Was ist, wenn die Zahlung fehlschlägt?
Was ist, wenn die Frist abläuft?
Was ist, wenn das System nicht verfügbar ist?
Was ist, wenn ein Mitarbeiter den Antrag ablehnt?

Modellieren Sie nur Ausnahmen, die für das Verständnis oder die Verbesserung des Prozesses relevant sind.

Schritt 10: Das Diagramm mit den Prozessinhabern überprüfen

Ein Diagramm sollte von den Personen überprüft werden, die die Arbeit ausführen. Sie können Folgendes identifizieren:

Fehlende Schritte
Falsche Zuständigkeiten
Inoffizielle Umgehungen
In Verfahren nicht dokumentierte Ausnahmen
Verzögerungen und unnötige Genehmigungen

12. Beispiel: Flussdiagramm-Version vs. BPMN-Version

Einfaches Flussdiagramm

Angenommen, ein Kunde gibt ein Produkt zurück:

Start
  ↓
Kunde beantragt Rückgabe
  ↓
Ist die Rückgabe zulässig?
 ├── Nein → Antrag ablehnen
 └── Ja → Rücksendeetikett senden
                ↓
          Zurückgesendetes Item erhalten
                ↓
          Erstattung ausstellen
                ↓
               Ende

Dies ist leicht zu verstehen und kann für Schulungen oder einen schnellen Überblick ausreichen.

BPMN-orientierte Version

Ein detaillierteres BPMN-Modell würde die Teilnehmer unterscheiden:

Kunde

Rücksendung anfordern
Produkt verpacken
Produkt versenden

Kundenservice

Rücksendeantrag prüfen
Rücksendung genehmigen oder ablehnen
Rücksendeanweisungen senden

Lager

Produkt erhalten
Zustand prüfen

Finanzen

Erstattung ausstellen

System

Bestätigung senden
Lagerbestand aktualisieren
Erstattung erfassen

Das Modell könnte auch Folgendes darstellen:

Eine Nachricht vom Kunden
Ein Timer für die Rückgabefrist
Ein Gateway basierend auf dem Produktzustand
Ein Fehler, falls der Artikel nicht eingegangen ist
Parallele Lager- und Erstattungsaktivitäten
Eine Nachricht, die die Erstattung bestätigt

Der Flussdiagramm erklärt die allgemeine Logik. BPMN erklärt die operative Zusammenarbeit.

13. Häufige Anfängerfehler

Fehler 1: Verwendung aller BPMN-Symbole

Anfänger versuchen manchmal, so viele Symbole wie möglich zu verwenden. Dies macht Diagramme schwerer lesbar.

Beginnen Sie mit:

Start- und Endereignisse
Aufgaben
Exklusive Gateways
Sequenzflüsse
Pools und Sparten
Nachrichtenflüsse, falls erforderlich

Fügen Sie erweiterte Elemente nur hinzu, wenn sie ein echtes Modellierungsproblem lösen.

Fehler 2: Verwechslung von Sequenzfluss und Nachrichtenfluss

Der Sequenzfluss zeigt den Fortschritt innerhalb eines Prozesses. Der Nachrichtenfluss zeigt die Kommunikation zwischen separaten Teilnehmern.

Verwenden Sie Nachrichtenflüsse nicht nur, um Linien anders aussehen zu lassen.

Fehler 3: Falsches Vermischen von Pools und Sparten

Verwenden Sie Sparten, um Verantwortlichkeiten innerhalb eines Teilnehmers aufzuteilen. Verwenden Sie separate Pools, wenn Teilnehmer unabhängige Entitäten oder Prozesse sind.

Zum Beispiel:

Vertrieb, Finanzen und Operations können Sparten innerhalb eines Unternehmens sein.
Kunde und Lieferant können separate Pools sein.

Fehler 4: Jede Entscheidung als exklusiv behandeln

Ein exklusives Gateway bedeutet, dass genau ein Pfad ausgewählt wird. Wenn mehrere Pfade gleichzeitig eintreten können, verwenden Sie ein paralleles Gateway. Wenn ein oder mehrere optionale Pfade eintreten können, erwägen Sie ein inklusives Gateway.

Fehler 5: Auslassen des Auslösers

Ein Prozess sollte erklären, was ihn auslöst. „Prozessauftrag“ ist vage, es sei denn, das Modell zeigt, ob der Auslöser ist:

Ein Kundenauftrag
Ein geplanter Batch
Eine Zahlungsbestätigung
Eine Nachricht von einem anderen System

Fehler 6: Nur den idealen Prozess modellieren

Echte Prozesse beinhalten Nacharbeit, Ablehnung, Verzögerungen und Eskalation. Ein Modell, das nur den idealen Pfad zeigt, mag attraktiv sein, ist aber operativ unvollständig.

Fehler 7: Zu viel Text innerhalb von Aktivitäten platzieren

Aufgabenbeschriftungen sollten im Allgemeinen ein prägnantes Verb-Objekt-Format verwenden:

Antrag prüfen
Adresse validieren
Erstattung genehmigen
Bestätigung senden

Vermeiden Sie lange Absätze innerhalb von Aufgabenboxen. Platzieren Sie unterstützende Erklärungen in Anmerkungen oder der Dokumentation.

Fehler 8: Erstellen eines einzigen riesigen Diagramms

Große Prozesse sollten in Teilprozesse unterteilt werden. Ein Diagramm auf hoher Ebene könnte Folgendes zeigen:

Bestellung entgegennehmen → Zahlung verarbeiten → Bestellung erfüllen → Bestellung abschließen

Jede Stufe kann mit einem detaillierteren Diagramm verknüpft werden.

14. BPMN-Best Practices für lesbare Diagramme

Beginnen Sie mit einem klaren Startereignis.
Beenden Sie mit einem oder mehreren sinnvollen Endzuständen.
Ordnen Sie den Hauptfluss von links nach rechts oder von oben nach unten an.
Halten Sie Sequenzflusslinien so gerade wie möglich.
Vermeiden Sie sich kreuzende Linien.
Verwenden Sie konsistente Aufgabenbezeichnungen.
Halten Sie das Hauptdiagramm auf einem lesbaren Detaillierungsgrad.
Verwenden Sie Bahnen nur, wenn die Zuständigkeit von Bedeutung ist.
Beschriften Sie Gateways mit sinnvollen Fragen oder Bedingungen.
Beschriften Sie ausgehende Gateway-Pfade, wenn die Bedeutung nicht offensichtlich ist.
Verwenden Sie Teilprozesse, um unnötige Details auszublenden.
Unterscheiden Sie normale Pfade von Ausnahmepfaden.
Halten Sie Nachrichtenflüsse zwischen geeigneten Pools.
Verwenden Sie Anmerkungen sparsam.
Validieren Sie das Modell mit Personen, die den Prozess durchführen.
Erstellen Sie bei der Neugestaltung eines Prozesses separate Diagramme für den „aktuellen Zustand“ und den „Zukunfts-Zustand“.

15. Wie viel BPMN sollte ein Anfänger lernen?

Sie müssen nicht die gesamte BPMN-Spezifikation lernen, um nützliche Diagramme zu erstellen.

Anfängerniveau

Lernen Sie:

Startereignisse
Endereignisse
Aufgaben
Sequenzflüsse
Exklusive Gateways
Parallele Gateways
Pools
Spuren
Nachrichtenflüsse
Basisdatenobjekte

Dies reicht für viele Geschäftsprozessdiagramme aus.

Mittleres Niveau

Hinzufügen:

Zeitereignisse
Nachrichtenereignisse
Fehlerereignisse
Teilprozesse
Aufrufaktivitäten
Benutzeraufgaben
Dienstleistungen
Grenzereignisse
Ereignisbasierte Gateways
Kompensationspfade

Erweitertes Niveau

Studieren:

Choreografiediagramme
Konversationsdiagramme
Nicht unterbrechende Ereignisse
Ereignis-Teilprozesse
Transaktionen
Kompensation
Mehrinstanzaktivitäten
Korrelation
Ausführungssemantik
Werkzeugspezifische Implementierungsregeln

BPMN unterstützt mehrere Modelltypen, darunter Prozess-, Kollaborations-, Choreografie- und Konversationsdiagramme. Anfänger sollten in der Regel zunächst mit gewöhnlichen Prozess- und Kollaborationsdiagrammen beginnen, bevor sie sich den spezialisierteren Typen widmen.

16. BPMN, Flussdiagramme und verwandte Notationen

BPMN ist nicht die einzige Modellierungssprache.

Flussdiagramme:Am besten geeignet für einfache Logik und Verfahren
BPMN:Am besten geeignet für Geschäftsprozesse und Workflow-Kollaboration
UML-Aktivitätsdiagramme:Nützlich für Software- und Systemverhalten
DMN:Nützlich für formale Geschäftsentscheidungen und Regeln
CMMN:Nützlich für flexible, fallbasierte Arbeit, bei der der Pfad nicht vollständig vordefiniert ist
Wertstromkarten:Nützlich zur Analyse des End-to-End-Werts und von Verschwendung
SIPOC-Diagramme:Nützlich für eine hochstufige Lieferanten-Eingabe-Prozess-Ausgabe-Kunden-Analyse

BPMN kann zeigen, dass eine Entscheidung getroffen wird, während eine entscheidungsorientierte Notation wie DMN die Regeln beschreiben kann, die zur Entscheidungsfindung verwendet werden. Diese Notationen können sich ergänzen, anstatt miteinander zu konkurrieren.

17. Eine einfache Daumenregel

Wählen Sie ein Flussdiagrammwenn:

Sie müssen eine Abfolge von Schritten oder Entscheidungen so schnell und einfach wie möglich erklären.

Wählen Sie BPMNwenn:

Sie müssen einen Geschäftsprozess verstehen, kommunizieren, analysieren, verbessern oder automatisieren, der Verantwortlichkeiten, Ereignisse, Systeme oder Organisationen umfasst.

Sie können auch beide verwenden:

Beginnen Sie mit einem einfachen Flussdiagramm, um den Gesamtprozess zu verstehen.
Konvertieren Sie es in BPMN, wenn Rollen, Nachrichten, Ausnahmen, Zeitpläne oder Automatisierung wichtig werden.
Erstellen Sie ein BPMN-Diagramm auf hoher Ebene für Führungskräfte und eine detaillierte Version für Analysten oder Entwickler.

Fazit

Flussdiagramme und BPMN sind nicht in jeder Situation konkurrierende Werkzeuge. Ein Flussdiagramm ist eine leichte visuelle Erklärung. BPMN ist eine strukturierte Modellierungssprache für Prozesse, die mehr Klarheit, Verantwortlichkeit und operative Details erfordern.

Für Anfänger ist der beste Ansatz, einfach zu beginnen:

Definieren Sie die Prozessgrenzen.
Identifizieren Sie die Beteiligten.
Kartieren Sie den normalen Pfad.
Fügen Sie Entscheidungen hinzu.
Weisen Sie Verantwortlichkeiten zu.
Fügen Sie nur dann Nachrichten, Timer, Daten und Ausnahmen hinzu, wenn sie relevant sind.
Verwenden Sie Teilprozesse, um die Komplexität zu steuern.

Wenn Ihr Prozess kurz ist und von einer Person oder einem Team bearbeitet wird, reicht ein Flussdiagramm wahrscheinlich aus. Wenn der Prozess mehrere Rollen, Abteilungen, Systeme, externe Parteien, Fristen oder Automatisierung umfasst, bietet BPMN in der Regel ein klareres und langlebiges Modell.

Der Artikel ist auch in English, Español, فارسی and Français verfügbar.