Die meisten Teams, mit denen ich gesprochen habe, glauben, sie hätten Geschäftsprozessmodellierung durchgeführt. Sie haben etwas gezeichnet. Vielleicht in Lucidchart, vielleicht in einer Whiteboard-Session, die jemand fotografiert und danach nie wieder geöffnet hat. Sie haben den Idealablauf dokumentiert, ihn Prozessmodell genannt und sind weitergezogen.
Genau dieser Teil verursacht später Probleme.
Die Lücke zwischen dem Zeichnen eines Flussdiagramms und dem Aufbau eines Modells, das Ihnen tatsächlich etwas Nützliches sagt, ist größer, als die meisten Teams erwarten. Und diese Lücke erklärt ein Muster, das ich ständig sehe: Teams investieren Zeit in die Dokumentation von Prozessen und sehen dann zu, wie diese Dokumente verstauben, während dieselben Probleme in ihren Workflows immer wieder auftreten.
Dies ist ein Leitfaden zur Geschäftsprozessmodellierung, wie sie tatsächlich funktioniert – nicht wie sie üblicherweise beschrieben wird.
Wo die meisten Modellierungsinitiativen ins Stocken geraten
- BPM ist nur dann nützlich, wenn Regeln, Verantwortliche, Entscheidungspunkte und Fehlerquoten erfasst werden – nicht nur Aktivitätsabfolgen.
- Die Annahme, dass eine einmalige Dokumentation ausreicht, ist der Grund, warum die meisten Geschäftsprozesse nach der Modellierung weiterhin fehlerhaft bleiben.
- BPMN und Process Mining machen aus einem statischen Diagramm ein umsetzbares Modell.
Was Geschäftsprozessmodellierung tatsächlich bedeutet
Geschäftsprozessmodellierung ist die Praxis, datenbasierte visuelle Darstellungen dafür zu erstellen, wie Arbeit tatsächlich durch ein Unternehmen fließt. Nicht so, wie sie ursprünglich geplant war. Sondern wie sie wirklich abläuft – einschließlich der Entscheidungspunkte, Übergaben, Verzögerungen und Stellen, an denen Dinge unbemerkt auseinanderfallen.
Die Definition von IBM beschreibt es so: Ein Geschäftsprozessmodell dokumentiert die Abfolge von Aktivitäten und Entscheidungen in einem Workflow, erfasst die beteiligten Personen und Systeme und liefert die Daten, die erforderlich sind, um die Leistung zu analysieren und Verbesserungspotenziale zu identifizieren. Es ist der operative Bauplan, den ein Architekt vor Baubeginn nutzen könnte – mit dem Unterschied, dass das Gebäude bereits in Betrieb ist, während Sie es zeichnen.
Diese Einordnung als „Bauplan“ ist die hilfreiche. Ein Geschäftsmodell ist keine Dekoration. Eine Darstellung von Geschäftsprozessen, die nur zeigt, was passieren sollte, ist ein organisatorischer Mythos und kein Modell. Der Wert liegt in der analytischen Ebene unterhalb der Visualisierung: den Zeitverläufen, Verantwortlichkeiten, Regeln für jede Entscheidung sowie Erfolgs- und Fehlerquoten, die zeigen, ob der Prozess tatsächlich funktioniert.
Geschäftsmodellierung arbeitet auf Prozessebene, nicht auf Aufgabenebene. Ein Workflow mit „E-Mail senden“ beschreibt eine Aufgabe. Ein Geschäftsprozessmodell zeigt, wer die E-Mail unter welcher Bedingung auslöst, was geschieht, wenn der Empfänger nicht innerhalb von 48 Stunden antwortet, wer für diesen Eskalationspfad verantwortlich ist und wie häufig die gesamte Abfolge erfolgreich abgeschlossen wird. Das ist der Unterschied im Umfang.
Die visuelle Darstellung ist lediglich die Schnittstelle für diese Daten. Erstellen Sie die Schnittstelle ohne Daten, erhalten Sie ein Bild. Erstellen Sie die Daten ohne Schnittstelle, kann sie niemand nutzen. Erst beides zusammen ergibt ein echtes Geschäftsprozessmodell.
Was ein Geschäftsprozessmodell enthalten muss, um nützlich zu sein
Hier ist das Muster bei Support-Warteschlangen, das ich am häufigsten sehe: Ein Team erstellt ein Modell, das den Idealablauf zeigt. Jeder Schritt geht vorwärts. Jede Entscheidung wird sauber aufgelöst. Das Modell sieht korrekt aus, wird genehmigt und hat dann nichts Nützliches zu sagen, sobald der tatsächliche Prozess zum ersten Mal abweicht.
Was ungefähr sofort passiert.
Ein Geschäftsprozessmodell zu erstellen, das echte Arbeit leistet, erfordert eine analytische Tiefe, die die meisten Teams überspringen. Die IBM-Dokumentation zur Prozessmodellierung beschreibt konkret, was eine End-to-End-Sicht auf den Lebenszyklus tatsächlich umfasst: nicht nur Aktivitäten, sondern auch Ereignisse, die den Prozess starten und beenden, Zeitverläufe für jeden Schritt, Verantwortliche für jede Aktivität, Entscheidungspunkte, die den Workflow verzweigen, sowie Erfolgs- oder Fehlerquoten, die zeigen, ob der Prozess seinen Zweck erfüllt.
Ein typisches Geschäftsprozessmodell, das nur Aktivitätsabfolgen erfasst, lässt die gesamte Diagnoseebene aus. Wenn Ihr Modell nicht zeigt, wer für jeden Schritt verantwortlich ist, können Sie keine Verantwortlichkeit zuweisen, wenn etwas fehlschlägt. Wenn es keine Zeitverläufe erfasst, können Sie nicht erkennen, wo sich Verzögerungen ansammeln. Wenn es keine Entscheidungslogik zeigt, können Sie nichts davon ohne Rätselraten automatisieren.
Die zentralen Elemente jedes Prozesses müssen vorhanden sein, bevor das Modell operativen Wert hat.
Die Kernelemente eines Geschäftsprozessmodells
Jedes Modell, das diese Bezeichnung verdient, benötigt diese Komponenten:
Eine grafische Darstellung der Prozessschritte in Reihenfolge – in der Modellierungsterminologie Aktivitäten – ist die Grundlage. Jede Aktivität ist eine Arbeitseinheit mit einem klaren Anfang und Ende. Sequenzflüsse verbinden sie und zeigen die Reihenfolge.
Gateways und Entscheidungspunkte sind die Stellen, an denen sich der Workflow verzweigt. Exklusive Gateways bedeuten, dass ein Pfad gewählt wird. Parallele Gateways bedeuten, dass mehrere Pfade gleichzeitig ausgeführt werden. Ein Modell ohne Gateways ist ein Diagramm mit einer geraden Linie. Die meisten realen Prozesse sind keine geraden Linien.
Ereignisse markieren, wann Dinge starten, stoppen oder ihren Status ändern – ausgelöst durch Zeit, ein externes Signal oder eine innerhalb des Prozesses erfüllte Bedingung.
Rollen und Verantwortliche weisen jeder Aktivität menschliche oder systemseitige Verantwortlichkeit zu. Ein Diagramm ohne Verantwortliche ist eine Sammlung von Kästen. Es sagt Ihnen, was passiert. Es sagt Ihnen nicht, wen Sie anrufen müssen, wenn es nicht funktioniert.
Datenobjekte erfassen, welche Informationen durch den Prozess fließen und wo sie erstellt, verwendet oder geändert werden.
Zusammen machen diese Komponenten aus einem visuellen Prozess etwas, über das Sie nachdenken und urteilen können, wenn etwas schiefläuft.
Wie Process Mining und Event Logs Modelle datenbasiert machen
Der ältere Ansatz zur Geschäftsprozessmodellierung verlief so: Stakeholder zusammenbringen, sie interviewen und den Prozess zeichnen, den sie beschreiben. Das Problem ist, dass Menschen beschreiben, wie der Prozess funktionieren sollte. Was in der Produktion tatsächlich passiert, ist oft anders – manchmal erheblich.
Process Mining verändert das. Statt ein Modell aus Interviews zu erstellen, bauen Sie es aus Event Logs: zeitgestempelten Aufzeichnungen, die Enterprise-Systeme jedes Mal erzeugen, wenn ein Prozessschritt ausgeführt wird. Data-Mining-Algorithmen analysieren diese Logs, rekonstruieren die tatsächlichen Pfade und machen Abweichungen, Engpässe und Fehlerquoten sichtbar, die Interviews nie offenlegen.
IBM weist darauf hin, dass Process Mining Daten aus Systemaufzeichnungen nutzt, um ein evidenzbasiertes Bild davon zu erstellen, wie Workflows tatsächlich ausgeführt werden – nicht wie sie für die Ausführung entworfen wurden. Das ist der Schritt, der Prozessmodellierung von Dokumentation zu Prozessanalyse mit Diagnosewert in Echtzeit macht. Ein aus Event Logs aufgebautes Modell findet die Ineffizienz, die niemand im Workshop erwähnt hat, weil niemand wusste, dass sie existiert.
Geschäftsprozessmodellierungsnotation: Warum BPMN zum Standard wurde
Bevor standardisierte Notationen existierten, zeichneten verschiedene Teams Prozesse unterschiedlich. Business-Analysten verwendeten Flussdiagramme. IT-Teams nutzten Entity-Relationship-Diagramme oder UML. Entwickler schrieben Pseudocode. Führungskräfte erhielten PowerPoint-Folien, die mit nichts anderem übereinstimmten. Wenn ein Prozess von der Analyse in die Implementierung übergehen sollte, musste jemand zwischen all diesen Darstellungen übersetzen – und bei Übersetzungen gehen Informationen verloren.
Business Process Model and Notation (BPMN) wurde genau entwickelt, um dieses Problem zu lösen. Es ist eine standardisierte grafische Sprache zur Erfassung von Aktivitäten, Interaktionen und Informationsflüssen in Prozessen, die sowohl für geschäftliche Stakeholder als auch für technische Teams lesbar ist. Die Notation ist so präzise, dass ein BPMN-Diagramm als Bauplan für die Automatisierung dienen kann, ohne eine separate technische Spezifikation zu erfordern.
Die BPMN-Dokumentation von ProcessMaker bringt den Diagnosewert gut auf den Punkt: BPMN-Diagramme zeigen nicht nur, was ein Prozess tut, sondern auch die strukturelle Logik, die bestimmt, wie er sich unter unterschiedlichen Bedingungen verhält. Das unterscheidet sie von einem informellen Prozessdiagramm. Ein BPMN-Diagramm macht jedes Entscheidungs-Gateway explizit, jeden Ausnahmepfad sichtbar und jede Verantwortlichkeitszuweisung auf einen Blick lesbar.
Der Vorteil einer Standardisierung zuerst ist real. Wenn ein Prozessdiagramm in einem Unternehmen existiert und niemand eine gemeinsame Notation verantwortet, erhalten Sie so viele Versionen wie Teams. BPMN gibt Ihnen eine gemeinsame Sprache. Ein Analyst kann ein Modell erstellen, es an ein IT-Team übergeben, und das IT-Team kann ohne Übersetzungssitzung mit der Implementierung beginnen. Deshalb wurde BPMN zum dominierenden Standard für funktionsübergreifende Prozessarbeit.
Beim Umfang lohnt sich Präzision. BPMN ist speziell für Geschäftsprozessdiagramme ausgelegt: Workflows mit Menschen, Systemen und Entscheidungen im Zeitverlauf. Es deckt Aktivitäten, Ereignisse, Gateways und Informationsflüsse ab. Es deckt keine Systemarchitektur, Datenbankbeziehungen oder Softwareobjekthierarchien ab – dafür kommen andere Notationen zum Einsatz.
BPMN im Vergleich zu anderen Modellierungssprachen: Wo jede ihren Platz hat
Teams, die sowohl Prozessmodellierung als auch Softwareentwicklung betreiben, begegnen regelmäßig der Frage nach der Notation: Wann sollten sie BPMN und wann etwas anderes verwenden?
Die kurze Antwort lautet, dass verschiedene Prozessmodelle unterschiedliche Probleme lösen. BPMN ist die richtige Notation für funktionsübergreifende Geschäftsprozesse: alles, was menschliche Aufgaben, Genehmigungen, Trigger aus externen Systemen und Entscheidungslogik umfasst, die nichttechnische Stakeholder verstehen und validieren müssen. Darauf greifen Business-Analysten und Operations-Teams zurück.
UML (Unified Modeling Language) erfüllt andere Zwecke. Sie wurde für Software Engineering entwickelt: Klassenstrukturen, Sequenzdiagramme, Use-Case-Modellierung und Zustandsautomaten für Objektverhalten. IT-Teams und Entwickler verwenden UML, wenn es um die interne Logik eines Softwaresystems geht, nicht um einen Geschäfts-Workflow.
Business Process Execution Language (BPEL) liegt zwischen Modellierung und Ausführung: Sie ist eine Spezifikationssprache zur Orchestrierung von Webservices und näher am Code als am Diagramm. Einige Automatisierungsplattformen können BPEL direkt als ausführbare Prozessanweisungen lesen.
Das Übergabeproblem entsteht, wenn Teams diese Darstellungen ohne Vereinbarung vermischen. Ein BPMN-Diagramm, das an ein IT-Team übergeben wird, das eine UML-Spezifikation erwartet hat, wird Reibung erzeugen. Die Wahl der Notation sollte zur Zielgruppe und zur nachgelagerten Nutzung passen. Wenn das Modell von einem VP Operations geprüft wird: BPMN. Wenn es an ein Engineering-Team übergeben wird, das ein Softwaresystem entwickeln soll: UML. Wenn beides erforderlich ist, erstellen Sie beides und machen Sie klar, was was ist.
Geschäftsprozessmodellierungstechniken, die Teams tatsächlich einsetzen
Nicht jedes Team benötigt den vollständigen akademischen Katalog an BPM-Techniken. Diejenigen, die in Business Analysis, Operations, IT und Automatisierungsarbeit regelmäßig eingesetzt werden, bilden eine praktische Teilmenge.
Die Unterscheidung zwischen Technik und Notation ist hier wichtig. BPMN ist eine Notation: eine visuelle Sprache zur Darstellung von Modellen. Eine Technik ist die Methode, mit der Sie das Modell erstellen, und der Zweck, für den das Modell ausgelegt ist. Sie können BPMN innerhalb mehrerer Techniken verwenden, so wie Sie dieselbe Grammatik in unterschiedlichen Arten des Schreibens einsetzen können.
Im Folgenden werden die Techniken behandelt, die tatsächlich in den Geschäftsprozessen vorkommen, die Teams verwalten und automatisieren möchten – ungefähr in der Reihenfolge, in der Teams ihnen begegnen. Für tiefergehenden Hintergrund zum breiteren Methodikraum lohnt sich die vollständige Lektüre des IBM Think-Überblicks zur Prozessmodellierung.
Der Prozessfluss von einfacheren zu komplexeren Techniken ist nicht nur akademische Abfolge. Teams, die direkt zur Simulation springen, ohne eine solide Ist-Aufnahme zu haben, simulieren häufig den falschen Prozess. Mit den Grundlagen zu beginnen, ist kein Anfänger-Verhalten. Es ist Disziplin.
Flussdiagramme und Prozesslandkarten: Wo die meisten Teams beginnen
Ein Flussdiagramm ist eine visuelle Darstellung des Prozesses als Abfolge von Schritten und Entscheidungen. Kästen, Rauten für Entscheidungen, Pfeile für die Richtung. Die meisten Menschen haben eines erstellt. Die meisten Menschen halten dies für Geschäftsprozessmodellierung.
Es ist ein Ausgangspunkt. Allein reicht es nicht aus.
Eine Prozesslandkarte zeigt, was passiert. Das ist für Kommunikation und Schulung tatsächlich nützlich. Ein Teammitglied, das neu in einem Prozess ist, kann dem Flussdiagramm folgen und die Abfolge verstehen. Eine Führungskraft kann erkennen, wo sich zwei Aktivitäten überschneiden. Das Problem ist, dass eine Prozesslandkarte nicht zeigt, warum etwas passiert, wer dafür verantwortlich ist, wie lange es dauert oder welcher Anteil der Fälle erfolgreich das Ende erreicht.
Ich sehe immer wieder, dass Teams hier aufhören. Sie erstellen eine Prozesslandkarte, präsentieren sie in einem Review und erklären die Modellierung für abgeschlossen. Dann fragen sie sich, warum sich nichts verbessert hat. Die Landkarte hat das Problem dokumentiert. Sie hat es nicht erklärt.
BPMN-Diagramme und Swimlane-Modelle für teamübergreifende Workflows
Wenn ein Workflow Teamgrenzen oder Systemgrenzen überschreitet, brechen informelle Prozesslandkarten schnell zusammen. Wer welchen Schritt verantwortet, wird unklar. Übergaben gehen verloren. Das Diagramm wird zur Quelle von Diskussionen statt zur Quelle von Klarheit.
BPMN-Diagramme mit Swimlane-Layouts lösen dieses Problem. Jede Swimlane steht für eine Rolle, ein Team oder ein System. Aktivitäten befinden sich in der Swimlane der Person oder Einheit, die sie verantwortet. Wenn ein Sequenzfluss von einer Swimlane in eine andere übergeht, ist die Übergabe explizit und sichtbar.
Für jeden Workflow mit Stakeholder-Gruppen, die sich nicht automatisch abstimmen – Sales übergibt an die Implementierung, Operations löst Finanzfreigaben aus, Marketing Operations übergibt Leads an das Sales-Development-Team – macht diese Technik das Prozessdiagramm für tatsächliche Prozessverbesserung nützlich statt nur für Dokumentation.
Die praktische Verbindung zur Automatisierung ist direkt. Wenn ein IT- oder Automatisierungsteam ein BPMN-basiertes Modell als Bauplan für einen Workflow auf einer Automatisierungsplattform verwendet, entspricht die Swimlane-Struktur fast direkt der Diagrammstruktur. Jede Swimlane-übergreifende Übergabe wird zu einem Trigger für die Prozessautomatisierung. Jedes Gateway wird zu einem bedingten Branch. Das Modell wird zur Spezifikation.
Simulation und datenbasierte Modellierung zur Prozessverbesserung
Simulation ist der Schritt, den die meisten Teams überspringen – und der Modellierung von rückblickender Dokumentation in zukunftsorientiertes Prozessdesign verwandelt.
Bei der Simulation erstellen Sie ein Modell mit realen Leistungsdaten: durchschnittliche Dauer jeder Aktivität, Häufigkeit jedes Entscheidungspfads, Fehlerquoten an zentralen Gateways. Anschließend führen Sie das Modell unter verschiedenen Bedingungen in die Zukunft fort. Was passiert mit dem Durchsatz, wenn Sie die Genehmigungszeit um 20 % reduzieren? Wohin verschiebt sich der Engpass, wenn Sie einer Phase einen zweiten Prüfer hinzufügen? Was kostet die aktuelle Fehlerquote an diesem Gateway auf Jahresbasis?
Das Modell beschreibt den Prozess nicht mehr nur. Es wird zu einem Werkzeug, um Änderungen zu testen, bevor Sie sie umsetzen – was einen offensichtlichen Wert hat, wenn die Alternative darin besteht, betriebliche Experimente in der Produktion durchzuführen.
So verbindet sich Modellierung auch mit einer Disziplin der kontinuierlichen Verbesserung statt mit einmaliger Dokumentation. Ein Modell mit integrierten Kennzahlen kann aktualisiert werden, wenn sich Prozessdaten ändern. Führen Sie es mit den Event-Log-Daten des letzten Quartals aus, vergleichen Sie es mit dem Quartal davor, und Sie erhalten eine Evidenzbasis dafür, ob Ihre Prozessoptimierung funktioniert oder sich nur so anfühlt. Prozessmodelle, die das leisten, werden nicht zu Ablageware. Sie werden zum laufenden Mechanismus, mit dem ein Team sich selbst misst.
Die tatsächlichen Vorteile der Geschäftsprozessmodellierung – und die, die überverkauft werden
Die echten Vorteile sind real. End-to-End-Transparenz darüber, wie Arbeit tatsächlich durch Ihre Geschäftsabläufe fließt, ist keine Kleinigkeit. Die meisten Unternehmen haben Abteilungen, die ihre eigene Arbeit verstehen, aber nur begrenzte Sicht darauf haben, wie diese Arbeit mit dem verbunden ist, was davor und danach passiert. Ein Modell, das den vollständigen Workflow abdeckt, legt Abhängigkeiten, Übergaben und Stellen offen, an denen sich Verzögerungen oder Nacharbeit ansammeln.
Die Identifikation von Engpässen folgt aus dieser Transparenz. Sie können keinen Engpass beheben, den Sie nicht sehen. Ein Modell mit Zeitverlaufsdaten zeigt Ihnen, wo sich Arbeit ansammelt, wo die längsten Wartezeiten auftreten und ob die Einschränkung bei einer Person, einem System oder einer Entscheidungsregel liegt. Das ermöglicht es, Prozessverbesserungsmaßnahmen anhand von etwas anderem als der lautesten Stimme im Raum zu priorisieren.
Strategische Ausrichtung ist der weniger diskutierte Vorteil. Laut IBM verbinden gut aufgebaute Prozessmodelle organisatorische Aktivitäten mit Kundenerwartungen und Geschäftsstrategie. Wenn Sie einen Prozess modellieren, der die Kundenerfahrung direkt beeinflusst, und erkennen können, wo der Prozess scheitert, können Sie operative Änderungen auf nachvollziehbare und belastbare Weise mit Kundenergebnissen verknüpfen.
Automatisierungsreife ist der Bereich, in dem ich die meiste Zeit mit diesem Thema verbringe. Geschäftsprozessmodellierung ist unverzichtbar, bevor Sie etwas automatisieren, das mehrere Systeme oder Teams berührt. Die McKinsey Global Survey on AI aus dem Jahr 2025 ergab, dass 62 % der Unternehmen mit KI-Agenten experimentieren, aber nur etwa ein Drittel begonnen hat, KI-Programme unternehmensweit zu skalieren. Diese Lücke zwischen Experimentieren und Skalierung ist häufig eine Lücke im Prozessmodell: Sie können einen Pilot ohne Modell durchführen, aber einen Workflow nicht zuverlässig im großen Maßstab automatisieren, wenn Sie Entscheidungspunkte, Verantwortliche und Ausnahmepfade nicht zuvor abgebildet haben.
Produktivitätssteigerungen folgen aus all dem, aber nur, wenn das Modell tatsächlich genutzt wird, um Veränderungen voranzutreiben. Optimieren Sie die richtigen Dinge, und die Produktivitätsverbesserung ist real. Modellieren Sie den Prozess, legen Sie das Dokument in einem Ordner ab und ändern Sie nichts, dann beträgt der Produktivitätseffekt exakt null.
Die überverkaufte Version verdient direkte Aufmerksamkeit. Geschäftsprozessmodellierung allein behebt keine Prozesse. Sie macht sichtbar, was behoben werden muss, und gibt Ihnen die Informationen, um es intelligent zu beheben. Teams, die Modellierung als Ziel statt als Diagnosewerkzeug behandeln, erstellen hervorragende Diagramme fehlerhafter Prozesse und wundern sich, warum sich nichts verbessert. Das Modell verändert nichts. Die Entscheidungen, die Sie auf Grundlage des Modells treffen, tun es.
📊 In der Praxis:
Ein gut aufgebautes Prozessmodell erfasst Ereignisse, Verantwortliche, Entscheidungspunkte, Zeitverläufe sowie Erfolgs- oder Fehlerquoten im gesamten Workflow. Diese Daten ermöglichen es einem Team, genau zu identifizieren, wo ein Prozess scheitert, wer dieses Scheitern verantwortet und wie häufig es geschieht – nicht als rückblickende Übung, sondern als laufende Prüfung der Betriebsfähigkeit. Prozessoptimierung erfordert diese Datenebene. Ein Modell ohne sie ist eine Zeichnung, kein Diagnosewerkzeug.
Wer Geschäftsprozessmodellierung nutzt und was diese Personen tatsächlich beheben wollen
Die richtige Frage lautet nicht, wer BPM nutzt. Sondern welches Problem diese Personen hatten, bevor sie damit begonnen haben, und was ihnen Geschäftsprozessmanagement gegeben hat, das sie ohne es nicht bekommen hätten.
- Business-Analysten, die aktuelle Workflows dokumentieren und verbessern
Business-Analysten nutzen BPM, um End-to-End-Transparenz in Workflows zu erhalten, die derzeit von jedem Stakeholder, den sie interviewen, unterschiedlich beschrieben werden. Bevor ein Modell existiert, lebt der Prozess in den Köpfen der Menschen in widersprüchlichen Versionen. Das Problem des Analysten besteht darin, widersprüchliche mündliche Beschreibungen in eine einzelne, kohärente Darstellung zu überführen, die alle validieren können. Erfolgreiches Geschäftsprozessmanagement gibt ihnen ein gemeinsames Artefakt, das angepasst werden kann, sobald sie mehr erfahren, statt eines statischen Dokuments, das ab dem Moment der Freigabe falsch ist.
- Operations- und Lean-/Six-Sigma-Teams, die Verschwendung und Variabilität reduzieren
Für Operations-Teams, die in Frameworks der kontinuierlichen Verbesserung arbeiten, ist das Modell das Messinstrument. Sie erstellen Modelle nicht, um den Prozess zu beschreiben – sie erstellen sie, um herauszufinden, wo sich Variabilität und Verschwendung ansammeln, damit diese beseitigt werden können. Die Analyseebene – Zeitverlaufsdaten, Fehlerquoten, Häufigkeiten von Entscheidungspfaden – macht das möglich. BPM ohne diese Daten ist wie ein Lean-Team mit einer Landkarte ohne Höhenlinien.
- IT- und Automatisierungsteams, die Prozessmodelle als Implementierungsbaupläne nutzen
Wenn ein Automatisierungsteam einen Workflow übernimmt, lautet die erste Frage: Was soll dieser Prozess tun, in welcher Reihenfolge, unter welchen Bedingungen und was passiert, wenn etwas schiefläuft? Ein gut aufgebautes BPMN-Modell beantwortet all diese Fragen in einem Format, das das Team direkt implementieren kann. Das Modell ist für sie keine Dokumentation – es ist die Spezifikation. Teams, die ohne ein solches Modell automatisieren, bauen in der Regel den Idealablauf und entdecken die Ausnahmefälle dann einzeln in der Produktion. Das ist ein vorhersehbares Support-Muster und kein angenehmes.
- Führungskräfte, die Geschäftsprozesse an der Unternehmensstrategie ausrichten
Auf Führungsebene geht es bei BPM darum, operative Aktivitäten mit strategischen Ergebnissen zu verbinden. Eine Führungskraft, die verstehen möchte, warum das Customer Onboarding drei statt einer Woche dauert, benötigt ein Prozessmodell, um zu sehen, wo diese Zeit über alle Abteilungen hinweg verbraucht wird. Die Geschäftsstrategiefrage – warum beeinflusst das die Kundenbindung? – kann nur beantwortet werden, wenn das operative Modell zeigt, wo sich Zeit und Fehler konzentrieren. Ohne das Modell bleibt die Diskussion auf der Ebene von Eindrücken. Mit ihm können Sie auf ein konkretes Gateway zeigen, an dem 40 % der Fälle ins Stocken geraten, und fragen, ob dies wirklich der richtige Ort für eine menschliche Genehmigung ist.
- SMB-Inhaber und RevOps-Führungskräfte, die automatisieren möchten, bevor sie verstehen, was sie automatisieren
Dieses Muster sehe ich im Support am häufigsten, und es ist keine Kritik. Kleine Teams bewegen sich schnell. Eine RevOps-Führungskraft oder ein SMB-Inhaber erstellt oft automatisierte Workflows ohne formelles Modell, weil keine Zeit für irgendetwas Formelles vorhanden ist. Die Folge ist, dass die Automatisierung die fehlerhafte Version des Prozesses einschließlich aller undokumentierten Ausnahmen getreu repliziert. Eine Initiative zum Geschäftsprozessmanagement muss nicht formal sein, um nützlich zu sein. Selbst ein schlankes Modell, das Verantwortliche und Entscheidungslogik dokumentiert, bevor die Automatisierung beginnt, würde die Hälfte der nachfolgenden Tickets verhindern.
Geschäftsprozessmodellierung vs. Geschäftsprozessmapping: Der Unterschied, der die meisten Teams aus dem Konzept bringt
Diese Verwirrung tritt ständig auf, und sie hat echte Folgen.
Eine Prozesslandkarte zeigt die Abfolge von Aktivitäten in einem Workflow. Sie beantwortet die Frage: Was passiert und in welcher Reihenfolge? Das ist für Schulungen, Kommunikation und erste Dokumentation tatsächlich nützlich. Es ist das Diagramm. Das meinen die meisten Teams, wenn sie sagen, sie hätten Prozessmodellierung betrieben.
Ein Prozessmodell ergänzt die Abfolge um die analytische Ebene. Regeln, Daten, Entscheidungslogik, Leistungskennzahlen, Verantwortlichkeitszuweisungen, Fehlerquoten und Zeitverläufe. Während eine Prozesslandkarte beantwortet, „was passiert“, beantwortet ein Prozessmodell außerdem: „unter welchen Bedingungen“, „wie oft ist es erfolgreich“, „wer ist verantwortlich, wenn es nicht funktioniert“ und „wie lange dauert jeder Schritt tatsächlich?“
BPM in seiner vollständigen Bedeutung liegt viel näher am Modellierungsende dieses Spektrums. Es ist die Disziplin, evidenzbasierte Modelle aufzubauen und zu pflegen, die Analyse und kontinuierliche Verbesserung unterstützen – nicht nur Dokumentation. Geschäftsprozessmodellierung und -analyse als Praxis behandelt Modelle als lebendige Instrumente statt als abgeschlossene Liefergegenstände. Das Diagramm ist nur die Schnittstelle.
Der bestehende Prozess in Ihrem Unternehmen verfügt wahrscheinlich bereits irgendwo über informelle Landkarten, möglicherweise in Confluence oder Google Drive oder auf dem Miro-Board aus der Strategierunde von 2022. Was in den meisten Fällen fehlt, ist nicht das Diagramm. Es sind die Entscheidungslogik, Daten zu Fehlerquoten und Verantwortlichkeitszuweisungen, die aus dem Diagramm etwas machen, das Sie tatsächlich für Entscheidungen nutzen können.
Das ist die Lücke. Wer Prozessmapping mit Prozessmodellierung verwechselt, verschließt sich gegenüber allem, was den Modellierungsaufwand überhaupt lohnenswert macht.
So erstellen Sie ein Geschäftsprozessmodell, das Teams tatsächlich nutzen
Der häufigste Fehlermodus, den ich bei Initiativen zur Prozessmodellierung gesehen habe, ist ein Team, das ein methodisch korrektes Modell erstellt, das nach der Kick-off-Präsentation niemand mehr ansieht. Das Modell ist präzise. Das Modell ist detailliert. Das Modell liegt in einem Ordner. Nichts ändert sich.
Ein nützliches Geschäftsprozessmodell überlebt, weil es um die Fragen herum aufgebaut wurde, die Menschen tatsächlich beantwortet brauchen, mit Verantwortlichen, die einen Grund haben, es aktuell zu halten, und mit genügend analytischer Tiefe, um Probleme zu diagnostizieren statt sie nur zu beschreiben.
Die praktische Abfolge sieht so aus:
Grenzen Sie den Prozess zuerst ein. Versuchen Sie nicht, Ihr gesamtes Unternehmen in einem einzigen Vorhaben zu modellieren. Wählen Sie einen Prozess mit einem klaren Startereignis und Endzustand, einem messbaren Ergebnis und genügend Komplexität, damit sich die Modellierung auszahlt. Einen neuen Kunden onboarden, einen Verkaufsauftrag verarbeiten, ein Eskalationsticket bearbeiten – diese Prozesse sind ausreichend klar abgegrenzt, um sie korrekt zu modellieren, und wichtig genug, um den Aufwand zu rechtfertigen.
Identifizieren Sie Stakeholder und Verantwortliche, bevor Sie etwas zeichnen. Jede Aktivität im Modell benötigt einen Verantwortlichen. Wenn Sie mit dem Zeichnen des Diagramms beginnen, bevor Sie wissen, wem jeder Schritt gehört, werden Sie das Diagramm fertigstellen und dann feststellen, dass drei Aktivitäten entweder keinen oder sechs Verantwortliche haben. Beides sind Probleme.
Erstellen Sie das Ist-Modell, bevor Sie einen neuen Prozess entwerfen. Hier gehen die meisten Verbesserungsinitiativen aus Gründen schief, auf die ich im nächsten Abschnitt eingehe.
Validieren Sie mit Event-Daten. Wenn Ihre Systeme Event Logs erzeugen – und die meisten Enterprise-Systeme tun das –, vergleichen Sie Ihr Ist-Modell mit den tatsächlichen Log-Daten. Die Unterschiede zwischen dem, was Menschen beschrieben haben, und dem, was tatsächlich passiert, enthalten fast immer die wertvollsten Chancen zur Prozessverbesserung.
Entwerfen Sie den Soll-Zustand mit konkreten Verbesserungszielen. Sobald Sie wissen, was tatsächlich passiert und wo die Fehler liegen, entwerfen Sie die verbesserte Version mit messbaren Zielen: Reduzieren Sie diesen Schritt von vier Tagen auf einen, eliminieren Sie diese manuelle Umleitung durch Automatisierung des Entscheidungs-Gateways, senken Sie diese Fehlerquote von 22 % auf unter 5 %.
Ein Prozessdesign, das nicht auf dieser Abfolge aufgebaut wurde, ist spekulativ. Vielleicht haben Sie Glück. Häufiger investieren Sie in die Verbesserung der falschen Sache.
Den Ist-Prozess abbilden, bevor der Soll-Zustand entworfen wird
Teams, die die Ist-Dokumentation überspringen, entdecken dies fast immer nachgelagert, wenn das von ihnen erstellte Soll-Modell nicht dem tatsächlichen Systemverhalten entspricht, mit dem sie arbeiten.
Das Muster im Support sieht so aus: Ein Team entscheidet, einen Prozess neu zu gestalten oder zu automatisieren. Es hat ein allgemeines Verständnis davon, was der Prozess tut. Es entwirft die verbesserte Version, erstellt die Automatisierung und stößt dann auf eine Reihe von Ausnahmen, die es nicht berücksichtigt hat – weil diese Ausnahmen erst sichtbar wurden, als die Automatisierung in der Produktion auf sie traf. Jede Ausnahme steht entweder für einen komplexen Prozess oder einen Entscheidungspunkt, von dessen Existenz das Team nichts wusste, weil ihn während der Entwurfsphase niemand beschrieben hatte.
Ein Ist-Flussdiagramm, das aus tatsächlichen Workflow-Daten und nicht nur aus Stakeholder-Interviews erstellt wurde, bringt diese Ausnahmen ans Licht, bevor Sie irgendetwas bauen. Die Ineffizienz wird im Modell sichtbar statt in den Fehlerprotokollen der Automatisierung. Die Prozessflussanalyse zeigt die Fälle, die 30 statt 3 Tage dauern, die Genehmigungspfade, die viermal zurückschleifen, bevor sie aufgelöst werden, und die Entscheidungspunkte, an denen 60 % der Fälle in manuelle Bearbeitung fallen.
Diese Informationen prägen das Soll-Design auf eine Weise, die dafür sorgt, dass die Verbesserung tatsächlich funktioniert. Wenn Sie sie überspringen, ist Ihr Soll-Modell eine Wunschversion eines Prozesses, den Sie noch nicht vollständig verstehen.
Das richtige Tool für Geschäftsprozessmodellierung nach Reifegrad Ihres Teams auswählen
Die Tool-Auswahl bei BPM ist eine jener Entscheidungen, bei denen die Funktionsliste nicht das Wichtigste ist. Entscheidend ist, ob das Tool, das Ihr Team einführt, in sechs Monaten noch von Menschen genutzt wird, die nicht im Raum waren, als es eingerichtet wurde.
Das ist eine andere Frage als: „Welches Tool bietet die beste BPMN-Unterstützung?“
In einer frühen BPM-Reifephase sind zugängliche Tools die richtige Wahl: Lucidchart, Miro oder sogar draw.io. Die wesentlichen Tools für Geschäftsprozessmodellierung für ein Team, das gerade beginnt, seine Prozessdokumentation zu formalisieren, benötigen keine Simulationsfunktionen. Sie brauchen visuelle Klarheit, teilbare Links sowie die Möglichkeit, ohne Einrichtungsprojekt zu kommentieren und zusammenzuarbeiten. Vereinfachen Sie die Geschäftsprozessmodellierung in dieser Phase: Wählen Sie das Tool, das genutzt wird, statt desjenigen, das ein Komitee beeindruckt.
Bei Automatisierungsreife muss die Tool-Landschaft das Modell mit der Ausführungsebene verbinden. Ein BPMN-Modell, das in einem Diagrammtool liegt, ist ein hervorragendes Referenzdokument. Ein BPMN-Modell, das mit einer Automatisierungsplattform verbunden ist, wird zum Bauplan für den Workflow selbst. Hier kommen Plattformen wie Latenode ins Spiel – ein Team mit einem soliden BPMN-Modell seines Workflows für Genehmigungsrouting kann dieses direkt in eine funktionierende Automatisierung übersetzen: Das Absenden eines Formulars löst den Prozess aus, Entscheidungs-Gateways werden bedingten Branches zugeordnet und jeder Swimlane-Verantwortliche erhält beim jeweiligen Schritt eine Benachrichtigung. Das Modell liegt nicht in einem Ordner. Es wird zur Automatisierung. Für Teams, die an einer solchen Übergabe vom Modell zur Ausführung arbeiten, bedeutet eine Plattform mit vollständiger JavaScript-Logik und über 5.500 Integrationen mit automatischem OAuth, dass das Prozessmodell nicht vereinfacht werden muss, damit es zum Tool passt.
Für Projektmanagement-Kontexte oder Enterprise-Umgebungen erweitert sich die Frage nach der wesentlichen Software für Geschäftsprozessmodellierung um Governance, Versionierung und Organisationshistorie: Wer hat dieses Modell wann und warum geändert? Die meisten schlanken Diagrammtools beantworten diese Frage nicht. Prozessspezifische Plattformen wie Bizagi, Signavio und ARIS sind genau darauf ausgelegt.
Die Realität der Pflege ist folgende: Ein Tool, das Ihr Team nicht aktuell hält, ist schlimmer als gar kein Tool, weil es eine dokumentierte Version des Prozesses schafft, die langsam von der Realität abweicht, während alle so tun, als sei sie aktuell. Wählen Sie das Tool, das zum tatsächlichen Verhalten Ihres Teams passt, nicht zu seinem angestrebten Verhalten.
Dort beginnt das Ticket in der Regel.
Der Irrtum, der die meisten Projekte zur Geschäftsprozessmodellierung scheitern lässt
Drei Annahmen bringen die meisten BPM-Initiativen zu Fall, und sie sind so verbreitet, dass ich für jede eine Antwortvorlage schreiben könnte.
Die erste: BPM ist nur das Zeichnen von Flussdiagrammen. Diesen Punkt behandeln die vorherigen Abschnitte direkt. Ein Flussdiagramm ist die einfachstmögliche Darstellung einer Abfolge. BPM als Disziplin geht deutlich weiter: Regeln, Verantwortliche, Zeitverläufe, Kennzahlen, Entscheidungslogik und die laufende Praxis, das Modell mit der tatsächlichen Prozessleistung zu vergleichen. BPM als Zeichenübung zu behandeln, erzeugt Zeichnungen. Es erzeugt keine Prozessverbesserungen.
Die zweite: BPM ist nur für große Unternehmen. Die Vorstellung, BPMN und strukturiertes Geschäftsprozessmanagement seien Werkzeuge für Fortune-500-Unternehmen mit dedizierten Teams für Process Excellence, ist schlicht falsch. Sie hindert kleinere Unternehmen daran, Arbeit zu formalisieren, die ihnen direkt helfen würde. Ein Unternehmen mit 15 Mitarbeitenden und einem fehlerhaften Customer-Onboarding-Prozess hat denselben Nutzen von einem Prozessmodell wie ein Unternehmen mit 15.000 Mitarbeitenden. Das Format ist schlanker. Das Prinzip ist identisch. Die Fähigkeit, Engpässe zu identifizieren, Verantwortliche zuzuweisen und Abläufe zu optimieren, wird nicht erst ab einer bestimmten Mitarbeiterzahl relevant.
Die dritte: BPM ist eine einmalige Dokumentationsübung. Dies ist die schädlichste der drei Annahmen, weil sie verantwortungsvoll wirkt, während sie kontraproduktiv ist. Ein Team, das ein Modell erstellt, es in einem gemeinsamen Ordner ablegt und das Projekt als abgeschlossen betrachtet, wird ungefähr im ersten Monat ein präzises Modell haben. Danach erzeugt jede Änderung am tatsächlichen Prozess eine Lücke zwischen Modell und Realität. Das Modell wird irreführend statt nützlich. Business-User hören auf, ihm zu vertrauen, was rational ist. Und das Team verliert das einzige Instrument, das es zur Diagnose von Prozessproblemen hatte.
BPM ist eine kontinuierliche Disziplin. Das Ziel ist, Prozesse im Zeitverlauf zu optimieren, wenn sich Geschäftsbedingungen ändern, und nicht, einen Liefergegenstand zu produzieren, der beweist, dass das Team die Modellierungsübung durchgeführt hat. Die Behandlung als laufende Praxis statt als abgeschlossenes Projekt unterscheidet Teams, deren Modelle den Betrieb verbessern, von Teams, deren Modelle in Confluence liegen.
🤔 Denken Sie darüber nach:
Die Teams, die fortlaufende Prozessmodellierung am dringendsten benötigen – jene mit sich schnell ändernden Workflows, häufigen Problemen bei Übergaben und wiederkehrenden Fehlern in Automatisierungen – behandeln das Modell meist am ehesten als abgeschlossenen Liefergegenstand. Sie dokumentieren den Prozess einmal während einer Krise, sind zufrieden, dass er erfasst ist, und aktualisieren ihn nicht mehr. Sechs Monate später beschreibt das Modell einen Workflow, der nicht mehr existiert, und sie fragen sich, warum die daraus aufgebaute Automatisierung weiterhin Ausnahmen produziert.
