Während es für die Modellierung von Prozessabläufen mit BPMN einen verbreiteten Standard gibt, existiert nichts Vergleichbares um Rollen zu definieren und die Personen auszuwählen, die die Arbeitsschritte in einem Prozess durchführen. Daher können diese Fragestellungen in verschiedenen Systemen zur Prozessautomatisierung unterschiedlich gelöst sein.
Zumindest ein Grundprinzip findet sich aber in den meisten Systemen: Die Benutzer-Tasks werden in verschiedenen Lanes (Bahnen) platziert und dadurch jeweils einer bestimmten Rolle zugeordnet. So werden etwa die Benutzer-Tasks, die in einer Lane „Einkauf“ angeordnet sind, den Mitarbeitern der Einkaufsabteilung zugeordnet.
Doch nicht immer genügt dieses einfache Prinzip. Auf den ersten Blick mag die Rollenzuordnung in dem abgebildeten Prozess einer Beschaffungsanforderung ganz einfach aussehen: Der Prozess, der vom Antragsteller (Requestor) gestartet wird, verläuft anschließend zu einem Einkäufer (Buyer), der die erstellte Beschaffungsanforderung auf Vollständigkeit prüft (Check purchase requisition for completeness). Ist sie unvollständig (incomplete), wird sie anschließend vom Antragsteller überarbeitet (Rework purchase requisition) und zur erneuten Vollständigkeitsprüfung weitergeleitet. Ist die Anforderung vollständig, so folgen zwei parallele Tasks: Der Einkäufer wählt einen Lieferanten aus (Determine supplier), und der Antragsteller kann die Bestätigung der Beschaffungsanforderung ansehen (View confirmation of purchase requisition).
Damit der Prozess ausgeführt werden kann, muss festgelegt werden, welche Benutzer die Rollen Antragsteller (Requestor) und Einkäufer (Buyer) wahrnehmen können. Prinzipiell kann jeder Mitarbeiter Antragsteller sein, weshalb auch jeder Mitarbeiter den Prozess starten können sollte. Die Rolle Antragsteller wird daher mit der Gruppe aller Mitarbeiter verknüpft.
Die Rolle des Einkäufers sollen alle Mitglieder der Gruppe Einkaufsabteilung wahrnehmen können. Bei der Ausführung werden Benutzer-Tasks aus der Lane „Buyer“ somit allen Einkäufern in ihren Task-Listen zur Bearbeitung angeboten.
Gemäß der gleichen Logik werden die Benutzer-Tasks in der Requestor-Lane allen Mitarbeitern zur Bearbeitung angeboten – da ja alle Mitarbeiter Antragsteller (Requestor) sein können. Das ist aber nicht gewünscht. Zwar soll jeder Mitarbeiter eine Beschaffungsanforderung erstellen und damit den Prozess starten können, doch sollen die weiteren Tasks zur Überarbeitung der Anforderung und zur Lieferantenauswahl in jeder Prozessinstanz nur von einem einzigen Mitarbeiter durchgeführt werden, nämlich demjenigen, der die betreffende Beschaffungsanforderung erstellt hat. Hier muss also für die genannten Tasks die allgemeine Zuordnung der Gruppe aller Mitarbeiter auf den Prozessinitiator eingeschränkt werden, d. h. auf denjenigen, der die Prozessinstanz gestartet hat.
Bei den Tasks in der Einkäufer-Lane ist es schon eher sinnvoll, dass sie in den Task-Listen aller Einkäufer erscheinen. Hierdurch kann jeweils der nächste freie Einkäufer den Task übernehmen. Andererseits könnte man auch festlegen, dass immer genau derjenige Einkäufer die Lieferantenauswahl durchführt, der vorher auch die Beschaffungsanforderung geprüft hat – und deswegen schon weiß, worum es geht. Für diesen Fall muss die Zuordnung des Tasks „Determine supplier“ auf diesen einzelnen Einkäufer eingeschränkt werden.
Da der Task zur Vollständigkeitsprüfung unter Umständen mehrfach durchgeführt wird, könnte man hierfür festlegen, dass die erste Durchführung zwar ein beliebiger Einkäufer vornehmen kann, die weiteren Durchführungen aber wiederum nur von demjenigen übernommen werden sollen, der den Task beim ersten Mal bearbeitet hat und sich daher mit der Beschaffungsanforderung bereits auskennt.
Und schließlich könnte es hier sinnvoll sein, das 4-Augen-Prinzip anzuwenden. Da die Einkäufer ebenfalls Mitarbeiter sind, können sie selbst auch Beschaffungsanforderungen stellen. Damit sie nicht ihre eigenen Anträge prüfen können, darf der Task „Check purchase requisition for completeness“ von allen Einkäufern durchgeführt werden – außer von demjenigen, der die Beschaffungsanforderung erstellt hat.
Die aufgeführten Beispiele machen deutlich, dass es vielfältige Problemstellungen bei der Zuordnung von Benutzer-Tasks zu Personen gibt. Wie man solche Problemstellungen umsetzen kann, hängt vom verwendeten BPM-System ab. Zum Teil gibt es bereits vordefinierte Bausteine für manche dieser Zuordnungen – beispielsweise für die Zuordnung eines Tasks zum Prozessinitiator. Für andere Fragestellungen kann es erforderlich sein, die betreffende Logik zu programmieren. Beispielsweise bietet das von mir verwendete BPM-System „Bonita“ die Möglichkeit an, sogenannten Akteur-Filter zu erstellen, die dann im Prozess benutzt werden können.
Wie die genannten Aspekte in dem Beispielprozess konkret umgesetzt werden können, beschreibe ich in dem Buch „Prozessautomatisierung mit BPMN“ am Beispiel von Bonita. Der ausführbare Prozess ist auch im Download zum Buch enthalten.