BPMN-Beispiele aus Agentur, Kanzlei und Treuhand: drei Prozesse Schritt für Schritt

Wie sind die Beispiele aufgebaut?

Die drei Beispiele beschreiben Prozesse, wie sie in Agenturen, Kanzleien und Treuhandbüros täglich vorkommen. Da sich Diagramme auf einer Webseite nur eingeschränkt darstellen lassen, werden die Modelle als strukturierte Tabellen wiedergegeben: Lanes, Aktivitäten in Reihenfolge, Gateways mit ihren Ausgängen, Ereignisse und Nachrichtenflüsse. Aus diesen Angaben lässt sich jedes Diagramm in einem beliebigen BPMN-Werkzeug in wenigen Minuten nachzeichnen. Die Modelle folgen der deskriptiven Ebene und den Regeln von eCH-0158: von links nach rechts, Aktivitäten als Substantiv plus Verb, entscheidende Aktivität vor jedem exklusiven Gateway, jeder Zweig mit Endereignis ^[1].

Die Beispiele verwenden ausschliesslich Elemente, die in ISO/IEC 19510 definiert sind und in jedem standardkonformen Werkzeug zur Verfügung stehen ^[2]. Sie sind bewusst einfach gehalten und eignen sich als Vorlage für eigene Prozesse. In der Praxis kommen Varianten und Ausnahmen hinzu, die bei Bedarf in Unterprozessen oder in der analytischen Modellierung ergänzt werden.

Beispiel 1: Auftragsabwicklung in einer Agentur

Der Kunde erscheint als zugeklappter Pool oberhalb des Agentur-Pools; zwischen beiden fliessen die Nachrichten Anfrage, Angebot, Auftrag, Entwurf, Rückmeldung und Rechnung. Das ereignisbasierte Gateway nach dem Angebot zeigt eine typische Situation: Entweder trifft der Auftrag ein, oder nach 30 Tagen läuft eine Frist ab. Die Korrekturschleife nach dem Entwurf folgt dem Prozessmuster «Kontrollschleife mit Rückmeldung gleicher Daten», das eCH-0158 am Beispiel eines Gut-zum-Druck beschreibt: Die Schleife führt zurück, bis keine Korrekturen mehr nötig sind ^[1].

Aus dem Diagramm lassen sich sofort Fragen und Anforderungen ableiten: Wie viele Korrekturrunden sind im Angebot enthalten? Wer misst die Zeit, die die Kreation pro Runde aufwendet? Wird die Rechnung nach Aufwand oder pauschal gestellt? In einem Projekttool wie Flenio entsprechen die Tätigkeiten Aufgaben mit Zeiterfassung, die Korrekturrunden lassen sich als Checkliste verfolgen, und die Rechnung entsteht aus den erfassten Zeiten.

Beispiel 2: Mandatsannahme in einer Kanzlei

Die Konfliktprüfung ist ein typisches Beispiel für die Regel, dass vor einem exklusiven Gateway eine Prüftätigkeit steht. Das Gateway selbst entscheidet nichts; die Entscheidung entsteht in der Tätigkeit «Interessenkonflikt prüfen», und die Ausgänge werden mit dem Ergebnis beschriftet ^[1]. Der Zweig «Konflikt» endet in einem eigenen Endereignis, weshalb er nicht wieder zusammengeführt werden muss. Wie die Prüfung im Detail erfolgt, etwa anhand einer Liste früherer Mandate und Gegenparteien, ist eine Geschäftsregel, die ausserhalb des Diagramms beschrieben wird.

Für eine Kanzlei zeigt das Diagramm zudem, wo vertrauliche Informationen anfallen: Parteien und Gegenparteien werden schon vor der Mandatsannahme erfasst. Daraus entstehen Anforderungen an Zugriffsrechte und Aufbewahrung, die bei der Wahl einer Kanzleisoftware zu berücksichtigen sind. Wie solche Anforderungen formuliert werden, beschreibt der Beitrag Anforderungen formulieren.

Beispiel 3: Monatsabschluss im Treuhand

Die Schleife für fehlende Belege entspricht dem Prozessmuster «Kontrollschleife mit Rückmeldung verschiedener Daten»: Die Prüfung beginnt jeweils nach dem Eintreffen der Unterlagen, und es müssen nicht dieselben Unterlagen eintreffen wie zunächst angefordert ^[1]. Deshalb führt die Schleife zurück vor das Nachrichten-Zwischenereignis, nicht direkt zur Prüfung. Bleiben Belege aus, kann zusätzlich ein Mahnverfahren angeschlossen werden, für das eCH-0158 ein eigenes Muster beschreibt: Statt jede Mahnstufe einzeln zu modellieren, bestimmt eine Tätigkeit «Weiteres Vorgehen bestimmen» anhand von Geschäftsregeln, ob weitere Stufen folgen.

Was lässt sich aus den Beispielen lernen?

• Externe Beteiligte als zugeklappte Pools: Ihre internen Abläufe werden nicht modelliert, nur die Kommunikation.
• Entscheidungen brauchen eine Tätigkeit: Das Gateway zeigt nur die Verzweigung.
• Schleifen gezielt einsetzen: Die Position des Rücksprungs zeigt, worauf gewartet wird.
• Fristen sichtbar machen: Zeitgeber-Ereignisse und ereignisbasierte Gateways zeigen, was nach einer Frist geschieht.
• Geschäftsregeln auslagern: Wie geprüft wird, gehört in eine Regelbeschreibung, nicht ins Diagramm.
• Endereignisse mit Ergebnis beschriften: «Mandat eröffnet» ist aussagekräftiger als «Ende».

Vom Diagramm zu Anforderungen

Prozessmodelle sind eine ergiebige Quelle für Anforderungen an Software. Der IREB-Lehrplan beschreibt Prozessmodelle als Modelle für Funktion und Fluss, die mit UML-Aktivitätsdiagrammen oder mit BPMN ausgedrückt werden können ^[3]. Jede Tätigkeit, die ein System unterstützen soll, erzeugt funktionale Anforderungen; jede Frist und jedes Volumen erzeugt Qualitätsanforderungen; jeder Nachrichtenfluss zu einem externen Pool erzeugt Anforderungen an Schnittstellen oder Kommunikationswege. Wer vor der Auswahl einer Software die wichtigsten Prozesse modelliert, kann Anbieter gezielt nach der Unterstützung dieser Abläufe fragen.

Die Beispiele auf eigene Prozesse übertragen

Wer die Beispiele für die eigene Organisation nutzen möchte, beginnt mit dem Prozess, der am häufigsten vorkommt oder die meisten Probleme verursacht. Zuerst werden Start, Ende und Beteiligte festgelegt, dann der Normalablauf skizziert, danach die wichtigsten Varianten ergänzt. Ein erstes Diagramm entsteht oft in einem einzigen Workshop von zwei Stunden. Wie solche Workshops vorbereitet und moderiert werden, beschreibt der Beitrag Prozesse aufnehmen; die Symbole erklärt der Beitrag BPMN-Symbole und Gateways. Den Gesamtzusammenhang zeigt der Leitfaden BPMN 2.0 und Prozessmanagement.

Wie werden Varianten und Ausnahmen ergänzt?

Die drei Beispiele zeigen den Normalablauf mit den wichtigsten Varianten. In der Praxis kommen weitere Fälle hinzu: Ein Kunde zieht den Auftrag zurück, ein Mandat wird nach der Eröffnung beendet, Belege bleiben trotz Mahnung aus. Solche Fälle sollten nicht alle in dasselbe Diagramm gepackt werden, weil es sonst unübersichtlich wird. Bewährt hat sich, häufige Varianten im Hauptdiagramm zu zeigen und seltene Ausnahmen in Unterprozessen oder in einer kurzen textlichen Beschreibung festzuhalten. Für die genaue Analyse von Fehlern und Eskalationen bietet die analytische Modellierungsebene zusätzliche Symbole.

Ein praktischer Test für jedes Beispiel ist das Durchspielen eines echten Falls aus der letzten Woche. Lässt er sich vollständig entlang des Diagramms verfolgen, ist das Modell brauchbar. Bleibt er an einer Stelle hängen, fehlt ein Schritt, eine Entscheidung oder eine Schnittstelle. Diese Prüfung dauert wenige Minuten und deckt erfahrungsgemäss mehr Lücken auf als eine lange Diskussion über das Diagramm.

Wer die Beispiele im eigenen Werkzeug nachzeichnet, sollte die Bezeichnungen an die eigene Organisation anpassen und die Lanes nach den tatsächlichen Rollen benennen. So entsteht in kurzer Zeit eine erste Vorlage, die mit den Beteiligten besprochen und schrittweise verfeinert werden kann.

Ein weiterer Nutzen der Beispiele liegt in der Diskussion, die sie auslösen. Schon die Frage, ob die Konfliktprüfung in einer Kanzlei durch das Sekretariat oder durch die Anwältin erfolgt, oder ob die Agentur nach zwei Korrekturrunden zusätzliche Aufwände verrechnet, führt oft zu Klärungen, die vorher niemand ausdrücklich getroffen hatte. Das Diagramm wird so zum Werkzeug, um Regeln und Zuständigkeiten bewusst festzulegen, statt sie stillschweigend vorauszusetzen.

Gerade solche Klärungen machen den eigentlichen Wert der Modellierung aus, oft mehr als das fertige Diagramm selbst.

Wer mehrere Prozesse modelliert, sollte zudem darauf achten, dass Endereignisse eines Prozesses gleich benannt sind wie die Startereignisse der nachfolgenden Prozesse; so entsteht eine durchgängige Kette.