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.
[…] Bitte trennen: Prozesse und Geschäftsregeln […]
Hallo Jakob,
das ist ein wichtiger Beitrag für die BPM-Gemeinde. Wir sind aktuelle daran, die Nutzung von Rule Engines im Kontext unserer Workflow Engine zu evaluieren. Wir beginnen an einer anderen Stellen, der Bestimmung des Empfängers einer Freigabeaktivität. Ein typische Fall ist die Rechnungsfreigabe. Diese hängt häufig von Parametern wie Kostenstelle, Höhe des Betrags und Kompetenz von Anwender ab.
Das ist übrigens dann aich ein sehr interessanter Fall für doe Modellierung BPMN und Übergabe an eine Engine. Die Swimlane kann man ja noch leicht mit „Freigeber“ nennen, aber wie macht mans dann in der Workflow Engine.
Als Test für den Einsatz der Rule Engines Drools und iLOG im Rahmen einer 4 monatigen Praktiumsarbeit haben wir uns unseren internen Freigabeprozess ausgesucht. Auch hier haben wir festgestellt, dass es diverse Regeln gibt, wer für welchen Antragsteller die Freigabe macht
Über unsere Forschritte werden wir regelmäßig auf unserem Bog informieren: http://www.saperionblog.com
Gruß Martin
Noch eine Anschlussfrage zu meiner Feststellung zur Bestimmung des Empfängers durch die Rule Engine: Wie sollte man das gescheiterweise darstellen? genauso wie schon der letzten Grafik dargestellt? Mir scheint, dass man so das Diagramm nur unnötig aufbläht. Meine Idee wäre es, die Notation der Aktivität als auch der Gateways zu erweitern durch ein kleines Icon, das eine entsprechende Aussage macht. Bei der Aktivität ein Icon für die Bestimmung des Empfängers, ein anderes für die Steuerung der Anwendung. Auch für das Gateway ist der Einsatz der Rule Engine interessant. Nach Beendigung der Aktivität könnte die Rule Engine die Bedingungen für das Beschreiten der Ausgänge auswerten.
Vielleicht ist das aber auch schon in den OMG-Gremien besprochen worden?
Gruß Martin
Hallo Martin,
hier endlich meine Antwort auf Deine Fragen:
Nein, man sollte keine Rules an Gateways koppeln! Die Regelprüfung ist eine Aufgabe, die Aufwand erfordert, und eine Ressource, die sich darum kümmert. Und das sollte ja gerade nicht die Process Engine sein, die aber für sämtliche Gateway-Entscheidungen zuständig ist. Deshalb sollte man auch die Prüfung, wer eine Aufgabe erledigt, entweder in einen vorgelagerten Rule Task legen (das Ergebnis geht dann als Parameter in die User Task ein), oder man „versteckt“ das in der User Task, wenn es die Engine erlaubt. Eigentlich nicht schön, aber evtl. pragmatisch.
Viele Grüße
Jakob
[…] zu diesem Thema, und ich werde demnächst mal etwas ausführlicher dazu bloggen. Bis dahin gibt es hier einen sehr groben Einführungspost, und in unserem Praxishandbuch BPMN greifen wir das Thema ebenfalls […]