Endspurt. In den ersten beiden Episoden dieser kleinen Blogreihe haben wir uns mit dem WAS (dem Prozessziel) und dem WIE (dem sinnvollen Zusammenwirken der Prozessbausteine) beschäftigt. Abschließen möchte ich die Reihe mit den am Prozess beteiligten Akteuren – also dem WER.
Die Frage nach dem WER zur Designzeit
Zur Designzeit kann die Frage nach dem WER immer dann beantwortet werden, wenn dieser von vornherein feststeht. Dies ist dann der Fall, wenn die Bearbeitung einer Aufgabe immer einer bestimmten Rolle oder Personengruppe zuzuordnen ist. In BPMN können wir dies durch Zuordnen von Aktivitäten in Pools und Bahnen darstellen, die Rollen oder Gruppen repräsentieren: Ein eingehender Antrag wird beispielsweise von einem Frontdesk-Mitarbeiter entgegengenommen und erfasst. Ein Sachbearbeiter der Bestandsabteilung führt inhaltliche Prüfungen durch, und der Abteilungsleiter stimmt dem Antrag auf Basis der Prüfergebnisse zu oder lehnt diesen ab. Eine Prozess-Engine kann derartige Prozesse steuern und den zur Designzeit eingestellten Personen/Gruppen/Rollen die Aufgaben in einem Arbeitskorb (aka Postkorb, Taskliste, …) zur Erledigung anbieten. Gute Engines beinhalten des Weiteren auch Konzepte, mit denen sich Abwesenheiten und Vertreterregelungen sowie Weiterleitungen abbilden lassen.
Zur Designzeit ist es vorrangig wichtig, die Aufgaben innerhalb des Prozesses den entsprechenden Akteuren zuzuordnen. Wenn dies nicht ohne weiteres möglich ist, zum Beispiel, weil der zu wählende Akteur von den Eingangsdaten abhängt, kann die konkrete Entscheidung nicht zur Designzeit getroffen werden. Was aber zur Designzeit entstehen kann und sollte, ist die Identifikation der Stellen im Prozess, an denen der Akteur und die zugehörigen Regelwerke ermittelt werden müssen: Anträge ab einer Höhe von 250.000€ müssen immer durch den Bereichsleiter anstelle vom Abteilungsleiter abgesegnet werden. Dieses triviale Beispiel ließe sich sogar noch einigermaßen anschaulich in BPMN darstellen. Ein auf die Antragshöhe reagierendes Gateway steuert den Prozess entweder in die Aktivität „Antrag zustimmen oder ablehnen“ in der Bahn des Abteilungsleiters oder alternativ in die gleiche Aktivität in der Bahn des Bereichsleiters. Richtig schön ist das nicht, denn spätestens, wenn das Regelwerk komplexer wird oder man versucht, auch unvorhergesehene Situationen über das Prozessmodell zu regeln, tendiert letzteres schnell in Richtung einer sich explosionsartig ausbreitenden Wartungshölle. Einfacher ist es, in solchen Situationen die…
Frage nach dem WER zur Laufzeit
… zu stellen, bzw. durch spezielle Komponenten beantworten zu lassen. Dazu formuliert man die Identifizierung des Akteurs beispielsweise in Form von Geschäftsregeln und bindet diese dann an den relevanten Stellen ins Prozessmodell ein. Die auszuführende Aktivität erhält ihre Zuordnung zu einem Akteur nicht mehr aus dem Prozessmodell, sondern erst zur Laufzeit. Je nach Kontext (z.B. Höhe des konkret zu verarbeitenden Antrags) wird die Aktivität dann unterschiedlichen Rollen oder Gruppen zugeordnet, taucht dann dort im Arbeitskorb auf und kann erledigt werden.
Dieser Ansatz trennt ganz klar die Prozesslogik vom Regelwerk zur Auswahl des Akteurs. Beide Komponenten lassen sich so deutlich besser warten und können geschickt miteinander kombiniert werden. Ebenfalls keine gute Idee ist es, die Frage nach dem WER in der Fachlogik der Aktivitäten zu platzieren. Dies wäre z.B. der Fall, wenn eine maschinelle Aktivität innerhalb ihrer Fachlogik auch den Akteur für die Folgeverarbeitung ermittelt. Auch hier ergibt sich recht schnell eine schwer zu handhabende Vermischung. Und weiter noch: auch für die Wiederverwendbarkeit kann sich dieser Ansatz als sehr nachteilig herausstellen, da die Entscheidung je nach aufrufendem Prozesskontext durchaus unterschiedlich aussehen kann.
Fazit
Mit dieser Forderung nach der sauberen Trennung der Verantwortlichkeiten (separation of concerns) möchte ich diese kleine Blogreihe schließen. Wir haben gesehen, dass die auf den ersten Blick trivialen Fragen nach WER, WIE und WAS durchaus gewissenhaft beantwortet werden sollten, um das Ziel von effektiven, effizienten und zugleich auch flexiblen Prozessen tatsächlich auch zu erreichen. Insbesondere die strikte Aufteilung von Verantwortlichkeiten auf dann gut kombinierbare Bausteine ist dabei das A und O.
