Bitte trennen: Prozesse und Geschäftsregeln

Ein wichtiger Bestandteil von Prozessen sind Wenn-Dann-Beziehungen, z.B.: „Wenn der Kunde ein Bestandskunde ist, dann gewähre ihm einen Rabatt“. Solche Beziehungen werden in Prozessmodellen mit Hilfe von Verzweigungsknoten dargestellt (auch inklusives / exklusives Oder bzw. „OR / XOR“ genannt). Auch in der Prozessautomatisierung und in der Programmierung müssen solche Knoten definiert werden, z.B. mit Hilfe des beliebten „If Kunde=Bestandskunde then allow discount“.

Problematisch wird es jedoch, wenn sogenannte Geschäftsregeln in Prozessmodellen abgebildet werden. Prozesstapeten, Schwierigkeiten bei der Modellverwaltung und der technischen Implementierung sind die Folge.

Das dargestellte Beispiel zeigt die Hinterlegung einer Geschäftsregel (Rabattierung) in einem Prozessmodell. Auf den ersten Blick ein durchaus übliches Vorgehen. Auf den zweiten Blick ergeben sich jedoch folgende Probleme:

• Je differenzierter die Rabatt-Regel, desto unübersichtlicher wird das Modell
• Möglicherweise spielt die Rabatt-Regel in unterschiedlichen Prozessen eine Rolle – dann muss sie redundant modelliert werden
• Sobald sich die Rabatt-Regel einmal ändert, muss das Prozessmodell angepasst werden
• Sofern eine Software den Prozess umsetzt, müssen Regeln auch noch in technischen Workflow-Modellen oder gar im Programmcode realisiert und kontinuierlich angepasst werden.

Regeln raus aus den Prozessmodellen
Klüger ist es, solche Geschäftsregeln in Formate auszulagern, die besser zur Abbildung geeignet sind, beispielsweise Tabellen. Solche Tabellen können die definierten Regeln zentral und übersichtlich vorhalten, und eine Anpassung einer zentral hinterlegten, und im Prozessmodell referenzierten Tabelle führt automatisch zu einer Implementierung der Anpassung im Tagesgeschäft (technisch oder organisatorisch).

Prozessmodell mit Regeln verknüpfen
Die Form der Referenz, wie also das Prozessmodell mit den separierten Regelwerken verknüpft ist, muss durch den Modellierer entschieden werden. Möglicherweise wird er dabei auch durch ein BPM-Tool unterstützt: Es ist beispielsweise denkbar und in vielen Tools inzwischen möglich, dass das anzuwendende Regelwerk in einem BPMN-basierten Prozessmodell als Datenobjekt visualisiert wird, und dass im BPM-Tool zu diesem Bild ein Link auf die Tabelle (z.B. als Excel-Datei) hinterlegt wurde. Sofern das Tool außerdem eine Web-Sicht auf das Modell ermöglicht, kann der Betrachter im Browser einfach auf das Datenobjekt klicken, und die Tabelle, nach der er sich zu richten hat, wird direkt geöffnet.

Process Engine mit Rules Engine koppeln

Richtig spannend wird es natürlich, wenn die definierten Geschäftsregeln durch eine Business Rules Engine ausgeführt werden können, um das jeweilige Ergebnis zu ermitteln. Wenn diese dann mit einer Process Engine gekoppelt sind, die zum entsprechenden Zeitpunkt die Rules Engine wie einen Service aufruft, und den Return-Parameter als Basis für die Verzweigung in die jeweiligen Pfade nimmt, schaffen wir drei Dinge:

• Transparenz: Wir wissen, welche Geschäftsregeln in welchen Prozessen zu welchen Ergebnissen führen – Stichwort Compliance
• Effizienz: Die automatische Anwendung von Regeln ist natürlich um ein vielfaches weniger aufwendig, als wenn solche Prüfungen durch einen Mitarbeiter vorgenommen werden
• Agilität: Durch die komfortable Erweiterung und Änderung von Regeln in Tabellen kann das Business endlich selbst einen entscheidenden Teil der Prozesslogik mitgestalten.

Wie das Ganze konkret funktionieren kann, sieht man u.a. am Beispiel der Kopplung von jBPM (Process Engine) und Drools (Rules Engine), die beide Open Source verfügbar sind.

Kurzum: Der ganze Prozesse-Regeln-Ansatz ist eine echte low-hanging-fruit, wenn es um die wirksame Anwendung von BPM und den berühmt-berüchtigten BPM-Kreislauf geht. Und für die Praxis deshalb kurzfristig auch viel spannender als die Frage, wie man jetzt BPMN-Diagramme nach BPEL überführt.

Schade, dass das viele Leute noch nicht kapiert haben.