Regelwerk

Zum Theme Business Rules Management System (BRMS) fand ich eben in meinen Feeds einen Beitrag von Column2, der sich auf die Gartner BPM Konferenz der letzten Woche bezieht. Auf dieser Veranstaltung hielt Marc Kerreman zum aktuellen Entwicklungsstand von Business Rules Management Systems einen Vortrag. Wie stark Business Rules in Geschäftsprozesse eingreifen und sie optimieren können, war darin Schwerpunkt.
Business Rules werden als implizite und explizite Regeln definiert, die eine Geschäftsaktivität definieren und beschreiben (wobei implizit meint, das die Regeln in Applikationen eingebettet sind).

Auf dieser Basis wurde an dem Gartner-Event diskutiert, in welchem Masse sich Geschäftsregeln innerhalb eines Unternehmens durch geografische oder andere regulatorische Faktoren stark unterscheiden können. Marc Kerreman beschrieb die Vorteile von Business Rules Managementsystemen (BRMS), um die Komplexität von Geschäftsregeln quer durch ein Unternehmen hinweg in den Griff zu bekommen. Wichtig für diesen Aspekt ist, wer die Regeln eigentlich verwaltet bzw. verantwortlich für sie ist. Das sind entweder

• Business Manager - sie bestimmen jene Regeln, die häufig geändert werden müssen, um geschäftliche Agilität sicherzustellen; sie definieren und verfassen vor allem die die weniger komplexen Regeln.
• Systemarchitekten verfassen die weiaus komplexeren Regeln und sind ausserdem dafür verantwortlich, dass das System reibungslos performt.
• Businessanalysten entwerfen neue Regeln - basierend auf ihren Analysen; sie erforschen und simulieren Regelszenarien.

In den letzten Jahren sind Business Rules zunehnmend in die Prozesse der Unternehmen integriert worden. Business Rules Engines (BRE) sind inzwischen in vielen BPMS integriert oder sind als eigenständiges System in die unternehmensweite IT eingepflegt worden. Nach Aussage von Kerreman sollte ein state-of-the-art BRMS folgende Komponenten enthalten.

• Rules engine: Ausführen, Sequenzieren und Verketten, darüber hinaus sollte eine moderne Rules engine die Ausführung eventbasierend betreiben können.
• Rule repository: in ihm werden die Regeln abgelegt bzw. bei Bedarf herausgeholt. Unbedfint gehört hierher ein Werkzeug, mit dem Zugriffsrechte verwaltet werden können. Eine Versionskontrolle gehört gleichfalls und wie selbstverständlich ins Repository.
• Rule modeling und Simulationen für What-if-Analysen: hier werden Abhängigkeiten zwischen den Regeln sichtbar, desgleichen wie sich Regeln auf die Gesamtperformance des Systems auswirken.
• Monitoring und Analyse auf historische und real-time Anwendung (inkl. Reporting und Audits).
• Rule-Management und Administration: (in Zusammenarbeit mit dem Repository) um die Sicherheit des BRMS zu gewährleisten. Sorgt für das Zusammenspiel von Entwicklung, Testing und Produktumgebungen. Hier werden die Änderungen und die Performance getrackt.
• Rule templates für die schnelle Erstellung industriespezifischer Vorlagen bzw. Regelsets.
• Regel-integrierende Benutzeroberfläche: es bietet eine grafische Oberfläche für das Erstellen, Testen und Fehlerbereinigen von Geschäftsregeln. Es stellt Werkzeuge für die einfache Entwicklung Regeln her, vorrangig für Benutzer ohne Programmierkenntnisse.

(Ich hätte an dieser Stelle vermutet, dass ein leistungtsstarkes Meta-Data-Management mit aufgeführt wird, dass für eine flexible Erstellung des Faktenmodells verantwortlich zeichnet.)

Vergleichbar mit BPMS werden nicht alle Anwender diese komplexe Funktionalität eines BRMS in gleichem Umfang nutzen. Entscheiden für einen Einsatz eines komplexen Management von Geschäftsregeln ist die Komplexitiät der Regeln. Grundsätzlich entscheidend für den Einsatz von regelbasierten Prozessen ist ja immer noch, wieviele Prozesse automatisierte werden können/müssen, wie komplex diese Prozesse sind und wie “teuer” es ein Unternehmen kommt, diese Prozesse nicht zu automatisieren. Entscheidend für den Einsatz eines ausgewachsenen BRMS ist deshalb immer noch, wie schnell ein Unternehmen auf Veränderungen am Markt reagieren können muss, wie agil ein Unternehmen sein muss.
Andere Argumtente für den Einsatz von BRMS beziehen sich darauf, dass mit seinem Einsatz einige Entscheide auf Geschäftsebene optimiert werden können:

• die Qualität und Konsistenz von Geschäftsentscheidungen selbst
• erhöhte Einnahmen durch eine optimale und marktgerechte Preispolitik (fine-tuning pricing rules on the fly)
• Kundenzufriedenheit durch optimale Anpassung an kundenspezifische Anforderungen
• Revisionssicherheit bzw. bessere Einhaltung gesetzlicher Bestimmungen durch den Einsatz geprüfter Regeln und erhöhter Transparenz bei Entscheidungsprouessen.

Bleibt noch zusammenzufassen, dass es unterschiedliche Herangehensweisen für BRMS gibt. Kerremans gibt als eine der best practices an, die eigenen Geschäftsregeln bzw. vor allem deren Votalität einmal zu untersuchen, um dann Prozesse zu bestimmen, mit denen Änderungen schnell und reibungslos ins System integriert werden können. So weit als möglich sollte eine natürliche Sprache benutzt werden (keine Begriffe und Definitionen, die vor allem Entwickler und dem IT-Personal geläufig sind). Damit wird gewährleistet, dass vor allem jene Verantwortliche, die die Regeln definieren und modifizieren, das dann auch tatsächlich tun können.