Prozessmodellierung
Die Prozessmodellierung ist die grafische Darstellung der Art und Weise, wie eine Arbeit abläuft: die Abfolge der Aktivitäten, die Rollen, die sie tragen, und die Entscheidungen, die ihren Lauf lenken, vom Auslöser bis zum Ergebnis. Dieselbe Wirklichkeit lässt sich als Flussdiagramm, in BPMN, als UML-Aktivitätsdiagramm oder als IDEF/IGOE-Diagramm zeichnen, vier Notationen, die dieselbe kleine Menge von Elementen ausdrücken und sich nach Publikum, Domäne, Grad der Formalität und Verwendung unterscheiden. Die Detailebene festzulegen wiegt so schwer wie die Wahl der Notation.
Ziel
Ein Prozessmodell ist ein standardisiertes grafisches Modell der Abfolge von Aktivitäten, durch die eine Arbeit ausgeführt wird. In seiner einfachsten Form löst ein Ereignis es aus, eine Kette von Aktivitäten schliesst sich an, ein Ergebnis beendet es; eine reichere Form fügt die Daten und Materialien hinzu, welche die Aktivitäten verbrauchen und erzeugen. Der Liefergegenstand ist ein Diagramm, meist begleitet von einem Text, der es dokumentiert.
Die Technik dient dazu, in einer Organisation Einigkeit darüber herzustellen, was sie tut. Sie beschreibt den Umfang einer Lösung, indem sie die Aktivitäten und die Beteiligten zeigt, die sie berührt, sie gibt einer Arbeit eine Lesart, der ein aussenstehender Beobachter folgt, ohne das Fachgebiet zu kennen, und sie liefert die Grundlage, ohne die die Prozessanalyse nichts zu messen hat. Ein Modell des Ist-Zustands baut ein gemeinsames Verständnis dessen auf, was heute geschieht; ein Modell des Soll-Zustands legt fest, was man erreichen will. Beide verwenden dieselben Elemente und dieselbe Notation; nur der Zeitpunkt im Projekt und die gestellte Frage unterscheiden sich.
Einsatz
Wann sie einzusetzen ist
- Einen Prozess verstehen, bevor man ihn ändert: allen Beteiligten dasselbe Bild dessen geben, was tatsächlich geschieht.
- Den Umfang einer Lösung abstecken: die betroffenen Aktivitäten und Beteiligten zeigen, bevor die Anforderungen erhoben werden.
- Stakeholder ausrichten: eine ausdrückliche Einigung über den Ist- oder den Soll-Zustand erzielen.
- Eine Prozessverbesserung vorbereiten: das saubere Abbilden des Ablaufs ist die Voraussetzung jeder Messung und jedes Vergleichs.
- Eine Automatisierung speisen: einer Ausführungs-Engine das formale Modell geben, das sie benötigt.
Wann sie nicht einzusetzen ist
- Die Komplexität liegt in der Entscheidungslogik: die Regeln getrennt mit der Entscheidungsmodellierung behandeln.
- Die Frage betrifft die Datenstruktur: ein Datenmodell oder ein Datenflussdiagramm vorziehen.
- Ein stark wandelnder, wegwerfbarer Prozess: ein gepflegtes Modell ist veraltet, bevor es gelesen wird, bei einem kurzen Text oder einer Checkliste bleiben.
Das Wahlkriterium
Da die vier Notationen dasselbe Vokabular ausdrücken, unterscheidet sie nicht, was sie sagen lassen: Die Wahl entscheidet sich am Publikum, das das Modell erreichen muss, und an der Verwendung, der es dienen wird. Vier Kriterien entscheiden darüber, und eines allein genügt oft.
Zuerst das Publikum: Ein nicht technisches Publikum folgt einem Flussdiagramm mühelos, wo eine reiche Notation es verliert. Dann die Domäne: Ein Geschäftsprozess verlangt eine Unternehmensnotation, ein Prozess, der in einer Software lebt, verlangt eine Entwurfsnotation. Die geforderte Formalität: Eine schnelle Abstimmung begnügt sich mit einer Skizze, ein Modell, das Organisationsgrenzen überschreitet oder eine Maschine steuert, verlangt eine präzise und eindeutige Notation. Schliesslich die Verwendung: Ein Modell für die Diskussion, ein Modell für die Ausführung und ein Modell zum Abstecken eines Umfangs verlangen nicht dieselben Mittel.
Vier Notationen decken nahezu alle Fälle ab, jede mit eigenen Symbolen, Leseregeln und ausgearbeiteten Beispielen. Das Flussdiagramm ist die einfachste und am weitesten verstandene Notation, jene, zu der man zuerst greift, um ein geteiltes und wenig förmliches Bild zu erhalten. BPMN ist die Standardsprache, sowohl vom Fachbereich als auch von der Technik lesbar, fähig, interne oder organisationsübergreifende kollaborative Prozesse zu beschreiben und eine Automatisierung zu speisen. Das UML-Aktivitätsdiagramm gehört zur Software-Domäne und dient, wenn der Prozess in einem bereits in UML ausgedrückten Entwurf steht. Das IDEF/IGOE-Diagramm legt Umfang und Grenzen fest, was eintritt, was die Arbeit lenkt, was herauskommt und was sie befähigt, bevor die Abfolge im Detail gezeichnet wird.
Mehr Details finden Sie in unserem BPMN-Tutorial.
| Ihre Absicht und Ihr Publikum | Notation | Warum sie passt |
|---|---|---|
| Ein geteiltes, wenig förmliches Bild für ein nicht technisches Publikum erhalten und sich darüber einigen, was der Prozess ist. | Flussdiagramm | Die einfachste und meistgelesene Notation; Swimlanes ergänzen üblicherweise die Rollen. |
| Ein präzises Modell, sowohl vom Fachbereich als auch von der Technik lesbar, gegebenenfalls organisationsübergreifend oder für die Ausführung bestimmt. | BPMN | Standardsprache, reich an Ereignissen und Entscheidungspunkten; Pools und Swimlanes trennen die Beteiligten; sie kann eine Automatisierungs-Engine speisen. |
| Ein Prozess, der in einem bereits in UML beschriebenen Software-Entwurf steht. | UML-Aktivitätsdiagramm | UML-Diagramm zur Realisierung von Anwendungsfällen; Partitionen für die Verantwortung, Synchronisation der Parallelität. |
| Umfang und Grenzen eines Prozesses festlegen, bevor seine Abfolge im Detail beschrieben wird. | IDEF / IGOE | Rahmt die Eingaben, Vorgaben, Ausgaben und Hilfsmittel; für den Umriss gebaut, nicht für den detaillierten Ablauf. |
Darstellungsebenen
Die Wahl der Notation bindet Sie im Übrigen weniger, als es scheint. Ein Prozess lässt sich auf mehreren Detailebenen zeichnen, deren jede eine andere Sichtweise bedient, und diese Ebene einzustellen wiegt so schwer wie die Wahl der Notation. Hier verfehlt ein Modell oft sein Ziel: Eine zu hohe Ebene verbirgt die operativen Probleme, eine zu feine Ebene wird unlesbar und niemand kann sie noch validieren.
| Ebene | Was man sieht | Wozu sie dient |
|---|---|---|
| Kontext / Unternehmen | Der Prozess als Ganzes und seine Verbindungen zu den benachbarten Prozessen, ohne das Detail der Schritte. | Ein allgemeines Verständnis und die Einordnung des Prozesses in die Organisation. |
| Operativ | Die feingranularen Aktivitäten, die Ausnahmen und die alternativen Pfade. | Die reale Arbeit analysieren, die Reibungspunkte erkennen, eine Verbesserung vorbereiten. |
| System | Die Abfolge, formalisiert bis zu dem Punkt, an dem eine Maschine sie simulieren oder ausführen kann. | Als Grundlage für eine Simulation oder eine Automatisierung dienen. |
Ein gemeinsames Vokabular in vier Alphabeten
Wenn die Wahl wenig bindet, dann weil sich die Notationen in ihren Symbolen unterscheiden, nicht in dem, was sie beschreiben. BABOK zählt die Elemente auf, die jede von ihnen ausdrückt, und es sind stets dieselben. Eine Aktivität ist ein Schritt im Prozess, der sich selbst in einen Teilprozess zerlegen lässt. Ein Ereignis ist ein Vorkommnis ohne Dauer, das den Fluss auslöst, unterbricht oder beendet. Der gerichtete Fluss ist die logische Abfolge, welche die Schritte verbindet, in Leserichtung gezeichnet. Ein Entscheidungspunkt teilt den Fluss in exklusive oder parallele Pfade oder führt sie wieder zusammen. Eine Verknüpfung schliesst das Modell an ein anderes Prozessmodell an. Eine Rolle bezeichnet die beteiligte Person oder Gruppe und knüpft an das Organisationsmodell an.
Diese Nähe zur alltäglichen Vorstellung einer Abfolge von Handlungen erklärt, warum die Modellierung Stakeholder ohne Ausbildung anspricht und warum der Wechsel von einer Notation zur anderen möglich bleibt. Das Modell hat überdies einen Wert, den die Zeichnung nicht zeigt: Es erzwingt einheitliche Bezeichnungen, es macht Verantwortlichkeiten und Übergaben sichtbar, und es bringt Gruppen zum Vorschein, an deren Beizug niemand gedacht hatte.
Zu vermeidende Fallstricke
Drei Fehler lauern, welche Notation auch gewählt wird. Zuerst die Entscheidungslogik in den Fluss zu mischen: Wenn jede Geschäftsregel zu einer Verzweigung wird, schwillt das Modell bis zur Unlesbarkeit an, während die Regeln für sich genommen besser zusammenhalten. Dann die Überzerlegung, jenes Modell, das so detailliert ist, dass keine einzelne Person es versteht, es validiert oder es freigibt. Zuletzt die Veralterung: In einem Umfeld, das sich bewegt, entfernt sich ein Modell, das nur Dokumentation ist, vom realen Prozess und wird zu einem Archiv, das niemand mehr konsultiert. Zu diesen dreien kommt ein kultureller Widerstand hinzu, da die Modellierung in manchen IT-Kreisen als ein alter, dokumentenlastiger Ansatz gilt, für den keine Zeit vorgesehen wird; man entschärft ihn, indem man das Modell auf der richtigen Ebene hält und es an eine Entscheidung bindet, der es dient.
KI-Überlegungen
Ein Sprachmodell ist bei mehreren Schritten dieser Technik nützlich. Es erstellt einen ersten Entwurf aus vorhandenem Material: die Notizen eines Interviews, eine schriftliche Prozedur oder eine Arbeitsanweisung werden zu einem Kandidaten-Ablauf, den ein Analyst schneller korrigiert, als er ein leeres Blatt füllen würde. Es meldet Ausnahmepfade, die ein erster menschlicher Durchgang oft übersieht, die Ablehnung, die Stornierung, die überschrittene Frist. Es harmonisiert die Aktivitätsbezeichnungen über mehrere Modelle derselben Domäne hinweg, und es übersetzt ein Modell von einer Notation in eine andere, wenn sich das Publikum ändert.
Seine Grenze ist fachlicher Natur und sie ist nicht verhandelbar. Die Maschine leitet einen Ablauf aus dem ab, was man ihr zu lesen gibt, samt den Fehlern und Auslassungen der Quelle; sie weiss nicht, was die Organisation wirklich tut, wenn kein Dokument es sagt, und genau dort verbergen sich die Umwege und Ausnahmen, die den Wert des Ist-Modells ausmachen. Zu validieren, dass ein Modell die reale Arbeit widerspiegelt, obliegt den Menschen, die sie ausführen. Die richtige Ebene und die richtige Notation für ein gegebenes Publikum zu wählen bleibt ein Urteil, ebenso wie eine Verzweigung zu verwerfen, die die KI erfunden hat und die keine Regel stützt. Jeder Vorschlag der Maschine ist ein Entwurf, der den Stakeholdern vorgelegt wird.
Aufwand
Der Aufwand hängt mehr von der Notation und der Ebene ab als von der Technik selbst. Ein Flussdiagramm zur Rahmung kostet einige Stunden; ein ausführbares, gepflegtes BPMN-Modell kostet viel und über lange Zeit.
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Niedrig bis mittel | Die Personen zusammenbringen, die den Prozess kennen, und die bestehenden Prozeduren sammeln. Der Ist-Zustand verlangt vor allem Zugang zu den richtigen Ansprechpartnern. |
| Durchführung | Niedrig bis hoch | Eine Sitzung genügt für ein Flussdiagramm zur Rahmung; ein detailliertes operatives Modell, mit seinen Ausnahmen und alternativen Pfaden, verlangt mehrere Workshops und eine Validierung durch die Beteiligten. |
| Dokumentation | Mittel bis hoch | Ein Modell zur Diskussionsunterstützung wird nach Gebrauch verworfen. Ein Modell, das der Spiegel des Prozesses bleiben oder dessen Ausführung steuern muss, wird bei jeder Änderung aktualisiert. |
Werkzeuge
Die Werkzeuge folgen dem Anspruch des Modells und der gewählten Notation. Ein Whiteboard und wiederablösbare Haftnotizen bleiben der schnellste Weg, ein Team zum Sprechen zu bringen und einen Ist-Zustand aufzunehmen. Ein generisches Diagrammwerkzeug erzeugt ein sauberes und versionierbares Modell, das für ein Flussdiagramm oder einen ersten BPMN-Entwurf genügt. Eine spezialisierte BPM-Suite drängt sich auf, wenn das Modell präzise, an ein Prozessrepository angebunden und auf Dauer gepflegt sein muss, mit Notationsvalidierung, Simulation und Versionsverwaltung. Die Notation schränkt das Werkzeug ein: Ein BPMN-Modell, das für die Ausführung bestimmt ist, setzt eine Engine voraus, die es interpretieren kann, was ein blosser Zeichnungseditor nicht ersetzt.
Quellen
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: die Definition der Technik und die Aufzählung der den Notationen gemeinsamen Elemente.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), Wissensgebiet Process Modeling: das massgebende Kompendium zur Prozessmodellierung und ihren Notationen, einschliesslich der IGOE-Linie.
- OMG, Business Process Model and Notation (BPMN) 2.0.2: die Spezifikation, die BPMN definiert.
- OMG, Unified Modeling Language (UML) Specification: die Spezifikation, die das Aktivitätsdiagramm definiert.
- NIST, FIPS PUB 183, Integration Definition for Function Modeling (IDEF0): der Bundesstandard, der die IDEF0-Funktionsmodellierung definiert.