(Unnötige) Fesseln in der Prozessmodellierung am Beispiel von ad-hoc Prozessen

Fesseln im BPM

Immer wieder mache ich (leider) die Erfahrung, dass in der Prozessmodellierung auf Teufel komm raus versucht wird, Tätigkeiten in eine logische Reihe oder Abhängigkeit zu bringen, ohne dass dies wirklich Sinn macht. Meist ein deutliches Zeichen, dass die Prozessmodellierung zum Selbstzweck eingesetzt und es versucht wird, sie zu stringent und starr und mit falschen Ansprüchen einzusetzen. Sicherlich nicht das einzige Beispiel, wie oft Formalismen und theoretische Annahmen das BPM bestimmen. Dennoch ein schönes Beispiel, was in der BPM-Praxis schief laufen kann. Ein Grund, einmal einen Blick auf die so genannten „Ad hoc“-Prozessen zu werfen, und wie man diese abbilden kann.

Prozesse und Ad-Hoc Prozesse

„Ein Geschäftsprozess besteht aus einer Menge logisch verknüpfter Einzeltätigkeiten (Aufgaben, Aktivitäten), die ausgeführt werden, um ein geschäftliches oder betriebliches Ziel zu erreichen“ (Wikipedia). Diese Definition gibt eigentlich das originäre Ziel einer Prozessdokumentation wieder: man will beschreiben, wann was zu tun ist. Es kommt also auch wesentlich auf die Reihenfolge der Tätigkeiten an. Also Motto: Ein Schritt nach dem anderen. Eine Beschreibung der Unternehmensabläufe in dieser Art macht auch für einen großen Teil der Prozesse Sinn: eine Einlagerung kann schließlich nicht vor einem Wareneingang stattfinden, oder eine Rechnung verbucht werden, bevor sie freigegeben worden ist. Die Vorteile einer solchen Beschreibung liegen auf der Hand: eine eindeutige und genau Beschreibung des Vorgehens, geeignet für jedermann, auch ohne Vorkenntnisse. Der Nachteil: sie sind starr und überlassen dem Handelnden wenig Freiraum.

Ein Ad-hoc-Prozess dagegen ist ein Ablauf, dessen zeitlich-logische Aufgabenfolge nicht festgelegt ist und für die Erfüllung der Aufgabe auch nicht wesentlich ist. Ein schönes triviales Beispiel ist hier die Aufgabe „Kaffee kochen“. Um Kaffee zu kochen, sind verschiedene einzelne Tätigkeiten notwendig, wie z.B. Kaffeepulver und Wasser einfüllen. Allerdings ist es hier irrelevant, ob zuerst das Pulver oder zuerst das Wasser eingefüllt wird, oder beides parallel. Das Ergebnis – der fertige Kaffee – ist immer das Gleiche. Ad-hoc Prozesse bieten hier also den Vorteil, zwar zu beschreiben, was zu tun ist, allerdings die Wahl der Reihenfolge der Abarbeitung der ausführenden Person zu überlassen. Sie überlassen der Person damit einen Freiraum und eine Flexibilität, „seine“ Aufgaben nach eigenem Ermessen zu erledigen. Dies kann ein wesentlicher Faktor sein, wenn es um Akzeptanz und Anwendung von Prozessmodellen geht. Wer – mal etwas überspitzt ausgedrückt – will sich von ein paar bunten Symbolen denn schon sagen lassen, wie er etwas zu tun hat. „Ich weiß oder kann das doch eh besser“.

Darstellung von Ad-hoc Prozessen in BPMN und EPK

In BPMN ist die Darstellung von Ad-hoc Prozessen kein Problem und sehr einfach, weil es dafür ein eigenes Objekt gibt. Das übergeordnete Objekt enthält dabei die Aufgabe, darunter verbergen sich die einzelnen Tätigkeiten, die in beliebiger Reihenfolge oder auch parallel abgearbeitet werden. Als Beispiel hier wieder „Kaffee kochen“.

Etwas komplizierter wird das Ganze bei der Darstellung in einer EPK. Dort gibt es ein solches Objekt nicht (zu mindestens kenne ich keins, bzw. nicht in der Grundausstattung). Dies ist, in Kombination mit den Konventionen für die EPK, wahrscheinlich auch mit eines der Gründe, warum dort zwanghaft versucht wird, eine Abfolge darzustellen. Dennoch gibt es auch hier Möglichkeiten, ad-hoc Prozesse darzustellen, z.B.

• man modelliert nur die Tätigkeit (Kaffee kochen), die einzelnen Tätigkeiten werden als Freitext daneben geschrieben
• man nutzt die Objektattribute, um dort die einzelnen Tätigkeiten zu erfassen
• man nutzt Anhänge an der Tätigkeit (Kaffee kochen), die die einzelnen weiteren Aufgaben enthalten. Hier bieten sich besonders Checklisten an, vor allem, wenn es viele zu erledigenden Tätigkeiten sind

ad hoc Prozesse in EPK

Mit Sicherheit sind das alles im Vergleich zu BPMN keine idealen Lösungen, dennoch besser als eine starre Abbildung einer Reihenfolge, die nicht unbedingt erforderlich ist.

Fazit

Aus meiner Sicht leidet das BPM und damit auch oder sogar vor allem die Prozessmodellierung daran, dass die Fesseln oft zu eng gezogen werden und Formalien über Sinnhaftigkeit regieren. Wenn Syntax vor Semantik kommt, stimmt etwas nicht und man braucht sich nicht zu wundern, wenn man seine (BPM) Ziele nicht erreicht. Ein passendes Beispiel hierzu ist die Darstellung von Prozessen, die keinem zeitlichen oder logischen Ablauf unterliegen. Die Darstellung als ad-hoc Prozesse verbessert nicht nur das Verständnis, sondern fördert zudem die Akzeptanz beim Anwender. Und genau das ist es, was es braucht, um BPM leben zu lassen.

Bildquellen:
Fesseln: Original André Karwath aka Aka, wikipedia