MS ProcessProzessmodellierung
Kontaktformular

BPMN 2.0

Ein Standard, der fachliche Abläufe präzise sichtbar macht.

BPMN 2.0 verbindet verständliche Visualisierung mit formaler Semantik. Genau deshalb eignet sich der Standard für professionelle Prozessmodelle.

Modellbeispiele

Prozessmodelle werden verständlicher, wenn sie erklärt werden.

Ein BPMN-Diagramm ist mehr als eine grafische Darstellung. Entscheidend ist, welche fachliche Aussage damit transportiert wird, welche Entscheidungen sichtbar werden und wie Beteiligte das Modell gemeinsam nutzen können. Die folgenden Beispiele zeigen eine erste interaktive Darstellungsform für solche Modelle.

Modellgalerie

Ausgewählte BPMN-Prozessmodelle aus Projekt- und Schulungskontexten.

Die folgenden Modelle zeigen freigegebene Auszüge aus unterschiedlichen Projekt- und Schulungskontexten. Einige Modelle wurden für die Veröffentlichung angepasst, damit keine kundenspezifischen Prozessinformationen offengelegt werden. Die Beispiele zeigen, wie BPMN-Prozessmodellierung aussehen kann und welche fachlichen Fragen sich innerhalb konkreter Modellierungsprojekte ergeben. Markierte Hotspots liefern zusätzliche Einordnungen direkt im jeweiligen Modell.

Bestellprozess

Vom Bedarf bis zur abgeschlossenen Bestellung

Das Modell zeigt, wie ein zuvor eher informeller Bestellablauf über E-Mail, Anruf und Einzelabsprachen in einen standardisierten Prozess überführt werden kann. Im Fokus stehen Formularnutzung, interne Abstimmung, Lieferantenkommunikation und die spätere Anbindung an ein ERP-System.

FormularStrukturierter Input durch das BestellformularDas Bestellformular bringt die benötigten Eingangsdaten in eine einheitliche Struktur. Dadurch wird das bisherige Datenchaos aus E-Mails, Telefonaten oder Einzelabsprachen reduziert. Wenn ein Bedarf telefonisch oder auf anderem Weg eingeht, kann der Beschaffungsmanager das Formular stellvertretend ausfüllen.RegelnAutomatisch unterstützte EntscheidungenDie Entscheidungen "Preis enthalten?" und "Preisgrenze überschritten?" zeigen exemplarisch, warum strukturierte Eingangsdaten wertvoll sind. Sind Preis, Artikelinformationen und Grenzwerte sauber erfasst, können fachliche Prüfungen automatisiert oder zumindest systematisch unterstützt werden.UnterprozessBestellung durchführen als eigener UnterprozessDer Unterprozess "Bestellung durchführen" wird über das Plus-Symbol als eingeklappter Detailprozess dargestellt und später in einem eigenen Modell genauer ausgearbeitet. Weil die Bestelldaten zu diesem Zeitpunkt strukturiert in der Datenbank vorliegen, kann die eigentliche Durchführung der Bestellung konsistent und nachvollziehbar erfolgen.

Bewerbungsprozess

Ein strukturierter Ablauf mit fachlicher Prüfung

Das Modell gibt eine fachliche Übersicht über den Bewerbungsprozess und unterstützt die interne Wissenskommunikation. Es entstand auf Basis eines kompakten Workshops und macht sichtbar, welche Systeme beteiligt sind und wo für eine technische Umsetzung weitere Detaillierung nötig wäre.

RECREC-System als zentrale ProzessanwendungDas REC-System ist die zentrale Anwendung, über die der Bewerbungsprozess bereits läuft. Im Modell wird sichtbar, wie das System durchgängig in den Prozess eingebunden ist. Gleichzeitig zeigt der Ablauf, an welchen Stellen die bisherige Nutzung stärker strukturiert und prozessorientiert weiterentwickelt werden soll.VorsortierungSystemgestützte Vorauswahl von BewerbungenEin wichtiger Teil des Workshops war die Frage, wie die Vorauswahl vieler eingehender Bewerbungen systemseitig unterstützt werden kann. Dafür steht ein neues Feature der bestehenden Infrastruktur zur Verfügung, das als Applicant Tracking System (ATS) eingebunden wird. Das inklusive Gateway zeigt, dass weiterhin eine manuelle, eine automatische oder eine kombinierte Bearbeitung möglich bleiben soll.FehlerlogFehlerprotokoll für nicht erkannte FormateWenn das neue System ein Bewerbungsformat bei der automatischen Beurteilung nicht korrekt erkennt, soll der Fehler automatisch protokolliert werden. Diese Dokumentation war fachlich wichtig, damit Formatfehler nachvollziehbar ausgewertet und die Erkennungsqualität des Systems kontinuierlich verbessert werden können.KriterienStrukturierte Kompetenzkriterien der FachabteilungenDie benötigten Kompetenzkriterien sollen künftig in strukturierter Form von den suchenden Fachabteilungen an die Personalabteilung übermittelt werden. Dadurch kann die Personalabteilung Bewerberinnen und Bewerber gezielter anhand der fachlich erforderlichen Kompetenzen filtern und auswählen.

Büromaterial bestellen

Ein kompaktes Modell mit Beschaffungslogik

Dieses Modell bildet den Unterprozess des internen Bestellprozesses ab: die tatsächliche Bestellung beim Lieferanten. Sichtbar werden die Lieferantenkommunikation sowie Bezüge zu Dokumentenmanagement und SAP.

StartStart aus dem übergeordneten BestellprozessDer Prozess "Büromaterial bestellen" beginnt nicht isoliert, sondern wird im übergeordneten Bestellprozess vorbereitet. Der konkrete Trigger ist das hausinterne Bestellformular, das beim Einkauf eingeht und dort den Beschaffungsprozess startet.EreignisseEreignisbasierte Reaktion auf LieferantenrückmeldungenDas ereignisbasierte Gateway zeigt, wie unterschiedlich auf das zuerst eintretende Ereignis reagiert werden kann. Nach der Verfügbarkeitsanfrage wartet der Prozess beispielsweise auf eine Zusage, eine Nichtverfügbarkeit oder den Ablauf einer Frist. Bei einer Zusage kann die Bestellung aufgegeben werden; bei Nichtverfügbarkeit oder ausbleibender Rückmeldung wird eine weitere Lieferantenklärung ausgelöst.AutomatisierungAutomatisierte Pflege von Bestell-, Rechnungs- und BestandsdatenEin wichtiger Folgeschritt ist die stärkere Automatisierung rund um Bestelldaten, Rechnungsdaten und Bestandsdaten. Besonders relevant ist die OCR-gestützte Extraktion von Rechnungsinformationen aus eingehenden Rechnungen. Die Daten sollen automatisiert vorbereitet und gepflegt werden, weiterhin mit menschlicher Prüfung an den relevanten Kontrollpunkten.

Auftragsprüfung

Prüfschritte, Sonderfälle und Ereignisse

Der Fokus liegt auf der Vorarbeit für eine KI-gestützte Auftragsprüfung. Wenn keine einfache Genehmigung möglich ist, wird ein KI-Agent mit Unternehmenskontext, aktuellen Daten und Richtlinien einbezogen, um zu genehmigen, abzulehnen oder an die Teamleitung weiterzuleiten.

EinordnungEmpfohlene Einordnung der GenehmigungsartAn dieser Entscheidung wird die Anfrage entweder in eine manuelle Freigabe oder in die neu zu implementierende KI-gestützte Sondergenehmigungsbearbeitung geleitet. Grundlage sind strukturierte Informationen aus der Anfrage, zum Beispiel Investitionsvolumen, Projektdauer oder Risikoeinschätzung. Bereits hier soll das System eine Einordnung empfehlen, die der Mensch anschließend bestätigen oder anpassen kann.KI-AgentAutomatisierter Ablauf der SondergenehmigungsprüfungIm unteren Prozessmodell ist der automatisierte Ablauf der Sondergenehmigungsprüfung dargestellt. Die eigentliche Komplexität des KI-Agenten steckt in der Aktivität "Genehmigung prüfen". Dafür müssen DMN-basierte Entscheidungslogiken und ein Agent mit geeigneten Bewertungsfähigkeiten entwickelt werden. Das Modell bildet hier zunächst das fachliche Grundgerüst und damit den Projektstart ab.RückkopplungTeamleiter-Rückkopplung bei unsicherer KI-EntscheidungWenn der KI-Agent keine belastbare Entscheidung treffen kann, erhält der Teamleiter eine Aufgabe zur Prüfung der Genehmigungsdaten. Er kann Zusatzinformationen ergänzen und die Anfrage überarbeitet an den Agenten zurückgeben, zum Beispiel mit Kontext zu Stammkunden, strategischer Bedeutung oder Projektrisiken. Der Agent verarbeitet diese Informationen erneut und trifft darauf basierend eine neue Entscheidung.AntwortVorkonfigurierte Rückantwort mit menschlicher EndprüfungAn dieser Stelle erhält die Auftragsprüfungsabteilung die Rückmeldung des KI-Agenten als vorbereitete Antwort an den Antragsteller. Nach dem Human-in-the-loop-Prinzip wird diese Antwort noch einmal fachlich geprüft und bei Bedarf angepasst. Im Idealfall muss der Mensch die vorkonfigurierte Rückmeldung nur noch freigeben und absenden.

Warenbestandsprüfung

Bestandslogik als schlanker Fachprozess

Ein bewusst übersichtliches Modell aus einer größeren Überführung von Excel-Prozessbeschreibungen nach BPMN. Die übersetzten Modelle wurden anschließend in Workshops mit Beteiligten reviewt und bei Bedarf angepasst. Es zeigt: Gute Prozessmodelle müssen nicht immer komplex sein.

LogiklückeLogiklücken bei der Überführung aus Excel-DokumentationenDie Überführung bestehender Excel-Prozessdokumentationen in ein visuelles BPMN-Modell macht häufig fachliche Logiklücken sichtbar. In der ursprünglichen Dokumentation war beispielsweise erwähnt, dass das BBS-System bei der Warenbestandsprüfung gelegentlich Fehler auswirft. Nicht beschrieben war, ob die Prüfung dann abbricht, weiterläuft oder welcher Folgeschritt ausgelöst wird. Im Review-Workshop wurde geklärt, dass die Aktivität durch ein unterbrechendes angeheftetes Fehlerereignis abbricht und die Bestandsprüfung anschließend erneut gestartet wird.DetailtiefeBewusst gewählte Detailtiefe des ProzessmodellsProzessmodelle können je nach Zielsetzung unterschiedlich detailliert sein. Dieses Modell bleibt bewusst abstrakt und dadurch übersichtlich. Eine tiefere Modellierung könnte zum Beispiel klären, was passiert, wenn ein Telefonanruf nicht angenommen wird, eine Telefonnummer falsch ist oder ein Rückruf vereinbart wird. Die passende Detailtiefe muss bewusst gewählt werden, weil BPMN-Modelle sonst bis auf kleinste Arbeitsschritte oder technische Ausführungsschritte anwachsen können.

Projektstart

Ausrichtung, Vorbereitung und Übergabe

Ein fortgeschritteneres Modell aus einem Kontext, in dem bereits BPMN-Grundwissen vorhanden war, die Modellkomplexität aber gezielte Unterstützung erforderte. Besonders die Arbeit mit Kompensationsereignissen zeigt hier ein höheres Niveau der BPMN-Syntax.

Call-AktivitätWiederverwendbarer ProzessbausteinDie Call-Aktivität verweist auf einen separat definierten Prozessbaustein, der an dieser Stelle aufgerufen wird. Im Kontext des Modells deutet das auf ein höheres BPMN-Modellierungsniveau hin: Die Anlage der Studierendendaten wird nicht als einfache Einzelaktivität verstanden, sondern als wiederverwendbarer Ablauf, der fachlich oder technisch an anderer Stelle genauer beschrieben werden kann.KompensationFangendes KompensationsereignisDas fangende Kompensationsereignis markiert, dass eine bereits ausgeführte Aktivität bei Bedarf rückgängig gemacht werden kann. Im Modell wird damit fachlich festgehalten, dass bestimmte Einrichtungsschritte nicht nur fehlschlagen können, sondern im Fehlerfall kontrolliert zurückgenommen werden müssen.RücknahmeKompensationsaktivitätDie Kompensationsaktivität beschreibt den fachlichen Rücknahmevorgang, zum Beispiel das Rückgängigmachen eines zuvor eingerichteten FG-Subnetz- oder VPN-Zugriffs. Sie ist nicht der normale Prozesspfad, sondern wird nur ausgelöst, wenn eine Kompensation erforderlich wird.AuslöserEintretendes KompensationsereignisDas eintretende Kompensationsereignis löst die Rücknahme der zuvor markierten Aktivitäten aus. Im Modell wird damit gezeigt, dass nach einem Fehler nicht nur dokumentiert wird, sondern gezielt ein definierter Rückabwicklungsmechanismus gestartet wird.GesamtlogikKompensationslogik bei Fehlern im ServerzugriffDie Modellierung mit Kompensationselementen gehört zu den erweiterten BPMN-Fähigkeiten und ist für fachfremde Betrachter nicht unmittelbar intuitiv. In diesem Modell wird sie bewusst verwendet: Tritt während des Unterprozesses "Studierenden Serverzugriff einrichten" ein Fehler auf, wird der Unterprozess abgebrochen und der Fehler dokumentiert. Anschließend wird das Kompensationsereignis "Serverzugriff rückgängig machen" ausgelöst, sodass bereits eingerichtete Zugriffe kontrolliert zurückgenommen werden.

Datenprüfung

Qualität, Rückfragen und Datenflüsse

Ein Schulungs- und Laborbeispiel, das typische BPMN-Konzepte verdichtet: ereignisbasierte Entscheidungen, angeheftete Zwischenereignisse, Kollaboration zwischen Prozessen und unterschiedliche Spezifikationen von Endereignissen.

StartereignisZeitbasiertes StartereignisDer Prozess startet über ein zeitbasiertes Startereignis. Die Datenprüfung wird damit nicht manuell im Einzelfall ausgelöst, sondern durch einen definierten Zeitpunkt oder Turnus angestoßen. Direkt danach folgt eine fachliche Vorbereitungsaktivität in der Controlling-Abteilung.Event-based GatewayEreignisbasierte Entscheidung mit ZeitereignisDas event-based Gateway modelliert eine ereignisbasierte Entscheidung: Der weitere Prozesspfad hängt davon ab, welches Ereignis zuerst eintritt. Entweder trifft die Bestätigung als Nachrichtenereignis ein oder ein zeitbasiertes Zwischenereignis nach 12 Stunden löst den alternativen Ablauf aus.GatewayEreignisbasierte Verzweigung nach SystemrückmeldungAn dieser Stelle wird die Rückmeldung aus dem SAP-System fachlich ausgewertet. Über die modellierte Verzweigung werden erfolgreiche Datenbearbeitung und Problemfall getrennt weitergeführt. Die nachfolgenden Nachrichtenereignisse sorgen dafür, dass der Nutzer passend zum Ergebnis informiert wird.FehlerpfadExklusives Gateway für irreparablen FehlerDas exklusive Gateway nach der Prüfung der KO-Kriterien trennt den regulären Ablauf vom Fehlerpfad. Bei einem irreparablen Fehler wird eine Dokumentationsaktivität ausgeführt und der Nutzer per Nachrichtenaktivität über den Prozessabbruch informiert.EndereignisTerminierendes EndereignisDas terminierende Endereignis beendet die Prozessinstanz vorzeitig. Es wird genutzt, wenn die Prüfung nicht weitergeführt werden soll, etwa weil eine notwendige Voraussetzung fehlt oder ein irreparabler Fehler dokumentiert wurde.NachrichtNachrichtenbasiertes Startereignis im SAP-SystemIm SAP-System startet der technische Prozess über ein nachrichtenbasiertes Startereignis. Die Nachricht aus dem fachlichen Pool löst die automatisierte Datenprüfung aus. Durch die getrennten Pools wird die Kollaboration zwischen Controlling-Abteilung und SAP-System sichtbar.Service TaskAutomatisierte Datenkorrektur als Service TaskDie automatische Datenkorrektur ist als systemseitige Aktivität modelliert und kann fachlich als Service Task verstanden werden. Sie beschreibt eine automatisierte Bearbeitung durch das SAP-System, bevor über weitere Gateways zwischen Metadaten- und Strukturdatenbearbeitung differenziert wird.NachrichtenendeNachrichten-Endereignis für erfolgreiche BearbeitungNach erfolgreicher Bearbeitung sendet das SAP-System über ein Nachrichten-Endereignis eine Rückmeldung an den fachlichen Prozess. Dort kann anschließend der Nutzer über die erfolgreiche Durchführung informiert werden.FehlerendeFehler-Endereignis mit ProblembeschreibungBei einem erkannten Problem wird zunächst eine Zusammenfassung erstellt und anschließend eine Problembeschreibung gesendet. Das Fehler-Endereignis markiert den technischen Abschluss des SAP-Prozesses als fehlerhaft und ermöglicht der fachlichen Seite eine gezielte Information des Nutzers.

Fertigungsauftragsverarbeitung

Operative Verarbeitung mit mehreren Beteiligten

Ein bewusst komplexitätsreduzierter Ausschnitt aus einem größeren Projekt zur Analyse von Fertigungsprozessen. Die eigentliche Prozesstiefe liegt in weiterführenden Unterprozessen. Das Modell zeigt, warum umfangreiche Abläufe besser geschachtelt statt in einem überladenen Diagramm dargestellt werden.

ERP-SystemERP-System als zentrale Daten- und KommunikationsdrehscheibeDas ERP-System ist in diesem Modell der zentrale Systembezug für Auftragsdaten und Statusinformationen. Besonders relevant ist die Kommunikation mit dem Lager: Rückmeldungen zu Freigabe, Stornierung oder Materialengpässen werden über Nachrichtenflüsse und Datenbezüge im Prozess sichtbar gemacht.Event-based GatewayEreignisbasierte Entscheidung zur VertriebsrückmeldungDas event-based Gateway wartet auf die Rückmeldung des Vertriebs. Tritt keine Rückmeldung ein, wird nach 48 Stunden erneut nachgefragt. Nach der dritten erfolglosen Rückfrage wird der Auftrag automatisch storniert. Das Modell zeigt damit eine klare ereignisbasierte Eskalationslogik.SubprozessFertigungsauftrag ausführen als eingeklappter SubprozessDie Aktivität "Fertigungsauftrag ausführen" ist als eigener Subprozess gedacht. Dadurch bleibt das übergeordnete Modell lesbar, während die operative Fertigung in einem separaten Detailmodell ausgearbeitet werden kann. Die angehefteten Ereignisse zeigen zugleich, dass dieser Subprozess laufend überwacht und bei Materialmangel unterbrochen werden kann.TimerNichtunterbrechendes zeitbasiertes ZwischenereignisDas angeheftete, nichtunterbrechende Zeit-Zwischenereignis erzeugt stündlich ein automatisches Statusupdate, ohne den laufenden Subprozess zu beenden. BPMN eignet sich hier gut, um wiederkehrende Begleitereignisse sichtbar zu machen, die parallel zur eigentlichen Fertigung stattfinden.NachrichtUnterbrechendes angeheftetes Nachrichten-ZwischenereignisDas angeheftete Nachrichten-Zwischenereignis reagiert auf die Meldung des Lagers, dass Material nicht verfügbar ist. Weil es unterbrechend modelliert ist, bricht es den Subprozess "Fertigungsauftrag ausführen" ab und leitet in den Pfad zur Kommunikation von Verzögerung und Rückstellung über.

BPMN für Ihre eigenen Prozesse nutzen?

Kontaktieren Sie mich gerne, vereinbaren Sie einen unverbindlichen Termin oder schicken Sie mir eine individuelle Anfrage zu Ihrem Prozessvorhaben.

Zum Kontaktformular