Geschäftsregeln in Unternehmensanwendungen
(Karslruhe, 25.04.2012) Geschäftsregeln – auch als “Business Rules” bekannt– finden sich in nahezu allen Bereichen und Prozessen eines Unternehmens wieder. Dies aber auch, dass die von Unternehmen eingesetzte IT-Systeme – sei es in Bereichen wie HR, Finance, ERP oder eben auch CRM – diese Regeln abbilden und anwenden können müssen.
In einer immer komplexer werdenden Welt, in der in immer kürzerer Zeit immer größere Datenmengen anfallen, die Grundlage für schnell zu treffende Entscheidungen sein sollen, stellt die effiziente Definition und Anwendung von Geschäftsregeln eine große Herausforderung für viele Unternehmen dar, die erfolgreich am Markt bestehen wollen.
Die Definition und Anwendung der Regeln als Bestandteil einzelner Anwendungssysteme über die gesamte IT-Landschaft hinweg verteilt, ist dabei nur bedingt zweckmäßig, da die Regeln oftmals als integraler Bestandteil des jeweiligen Systems – teilweise direkt im Programmcode – abgebildet werden. Auf diese Weise gibt es keinen Gesamtüberblick über die implementierten Regeln und auch eine Zuordnung von fachlich definierten Regeln zu den technisch umgesetzten Regeln ist schwer möglich. Weiterhin sind die auf diese Weise implementierten Regeln relativ statisch, d.h. eine Neudefinition oder Anpassung der Regeln kann nur mit erheblichem Zeit- und Kostenaufwand unter Einsatz spezialisierter Ressourcen (z.B. Programmierer) erfolgen. Die fachlich definierten Regeln hingegen, die aus den Gegebenheiten der realen Welt abgeleitet werden, sind dynamischer Natur, d.h. die unterliegen häufigen Änderungen.
Diesen Gegensatz – dynamische fachliche Regeln gegenüber statischen technischen Regeln – aufzulösen hilft Oracle Policy Automation (OPA). Im Folgenden soll erläutert werden, wie dies aussehen kann. Es wird im Weiteren von einer Integration von OPA mit Siebel CRM ausgegangen.
Was ist Oracle Policy Automation?
Oracle Policy Automation ist eine Software-Suite zum Modellieren, Verwalten, Anpassen und Anwenden von Geschäftsregeln.
OPA ermöglichst es, Geschäftsregeln zentral und unabhängig von der Implementierung der jeweiligen Anwendungssysteme (hier: Siebel) in einer Sprache, die nahe an der natürlichen Sprache ist, zu definieren. Weiterhin ermöglicht OPA die Definition der Regeln in MS Word und Excel – Anwendungen, die vielen Nutzern bereits vertraut sind. Durch dieses Konzept der Verwendung einer eingängigen Sprache mit bekannten Tools werden geschulte Fachanwender in die Lage versetzt, Geschäftsregeln bei Bedarf selbst anzupassen und zu erstellen. Auf diese Weise werden aus den statischen technischen Regeln wesentlich dynamischere Regeln, und der oben beschriebene Gegensatz wird deutlich entschärft.
Neben der Erstellung und Anpassung von Regeln ermöglicht OPA auch die Erstellung und Ausführung von sogenannten Interviews. Diese Interviews ermöglichen eine interaktive Erfassung von Daten und die Ausführung der definierten Regeln auf den erfassten Daten. Um mögliche Verwirrung zu vermeiden, soll an dieser Stelle kurz angemerkt werden, dass OPA nichts mit Haley bzw. mit Siebel Business Rules zu tun hat. Es handelt sich hierbei um vollständig verschiedene Produkte.
Komponenten, Architektur und Integration mit Siebel
Oracle Policy Automation besteht aus folgenden Komponenten:
- Oracle Policy Modeling (OPM): Dies ist das Tool zum Erstellen und zur Verwaltung von Geschäftsregeln und Interviews.
- OPA Runtime Components: Diese bestehen aus Oracle Web Determinations (Serverbasierte Ausführung von Interviews, die zuvor mit OPM definiert wurden), Oracle Determinations Server (serverseitige Ausführung von Regeln im Hintergrund, nicht interaktiv, auch im Batch möglich) und der Oracle Determinations Engine (Zuständig für die eigentliche Ausführung und Anwendung der Regeln, wird sowohl von Web Determinations als auch vom Determinations Server verwendet).
- OPA Konnektoren: Diese ermöglichen die einfache Integration von OPA mit Siebel, Oracle CRM on Demand und SAP. Grundsätzlich ist OPA selbstverständlich auch mit anderen Systemen integrierbar, für die drei oben genannten Systeme sind jedoch fertige Konnektoren verfügbar. Darüber hinaus beinhalten die Konnektoren bereits vollständig lauffähige Versionen von Web Determinations und des Determinations Servers, sodass eine separate Installation und Lizenzierung der Runtime Components nicht notwendig ist.
Wie aus dem Schaubild erkennbar erfolgt die Integration mit Siebel über EAI und UI-Integration, d.h. über Web Services und über die Einbindung von UI-Komponenten mittels Symbolic URLs. Durch die Verwendung von Standards wie Web Services ist selbstverständlich auch die Integration über eine Middleware möglich.
OPA hält selbst keine Daten in einer Datenbank, d.h. die Daten werden von Siebel an OPA übergeben, dort werden die Regeln auf die Daten angewendet und die Ergebnisse werden wieder an Siebel zurück übergeben. Eine eventuelle Weiterverarbeitung oder auf den Ergebnissen aufbauende Logik muss in Siebel separat implementiert werden.
Die Installation des Siebel Connectors in unproblematisch, erfordert jedoch teilweise ein manuelles Eingreifen. Es müssen zunächst die Runtime-Komponenten des Connectors installiert werden und anschließend Daten in das Siebel Repository importiert werden sowie administrative Daten in die Siebel Datenbank importiert werden. Für letzteres stellt Oracle einen Siebel Business Service zur Verfügung, der den Import übernimmt.
Nach der Installation steht ein Framework zur Verfügung, das in generischer Art und Weise die Integration von Siebel mit OPA ermöglicht. Eine Vielzahl möglicher Anwendungsfälle kann bereits mit dem Standard-Konnektor abgedeckt werden, jedoch ist die Funktionalität beliebig erweiterbar, indem die mitgelieferten Workflows und Business Services angepasst werden.
Erstellen von Geschäftsregeln
Wie sieht nun das Erstellen von Geschäftsregeln aus? Wie bereits erläutert erfolgt dies unter Verwendung von Oracle Policy Modeling und MS Word bzw. Excel. Ein einfaches Beispiel verdeutlicht die Vorgehensweise:
Angenommen folgende einfache Regel soll implementiert werden:
WENN das Telefonat länger als 30 Minuten gedauert hat
UND das Telefonat zwischen 18:00 Uhr und 24:00 Uhr geführt wurde
UND der Tarif des Besitzers Student 30+ heißt
DANN wende 10 % Rabatt auf das geführte Telefonat an.
Dieser Satz wird in der folgenden Form in Word eingegeben: wende 10% Rabatt auf das geführte Telefonat an wenn
das Telefonat länger als 30 Minuten gedauert hat und
das Telefonat zwischen 18:00 und 24:00 geführt wurde und
der Tarif des Besitzers 30+ heißt
Bei der Eingabe wird der Anwender durch ein Word-Add-In unterstützt, mit dem z.B. der erste Satz als eine „Conclusion“, also eine Schlussfolgerung deklariert wird. Die folgenden Sätze werden dann automatisch farblich gekennzeichnet und eingerückt. Das Add-In bietet auch einen Button zum Compilieren der Regel. Anschließend sieht die erstellte Regel dann so aus, wie in dem Screenshot dargestellt.
Aus dem Text werden automatisch Attribute extrahiert, welche dann auch in OPM dargestellt werden.
Es ist jedoch nicht nur möglich, die Attribute aus dem erstellten Regeltext ableiten zu lassen, sondern es gibt auch die Möglichkeit, ein in Siebel bestehendes Integrationsobjekt zu exportieren und direkt anschließend in OPM zu importieren. Es wird dann automatisch das OPA-Datenmodell mit den Entitäten, Attributen und den Beziehungen unter den Entitäten generiert. Die generierten Attribute, Entitäten und Beziehungen können dann während der Regelerstellung genutzt werden.
Dabei ist es auch möglich, komplexe Regeln zu erstellen, die mehrere Ebenen der Entitätsbeziehungen mit einbeziehen. So kann z.B. ermittelt werden, ob ein Mitglied eines Haushalts mindestens eine Adresse hat, die in einem bestimmten Land liegt. Basierend auf dieser Information können dann weitere Regeln definiert werden.
Einsatzmöglichkeiten
Die Verwendung von Oracle Policy Automation bietet sich immer dann an, wenn komplexe Geschäftsregeln abzubilden sind, die in Echtzeit ausgewertet werden müssen, häufigen Änderungen unterliegen und/oder unabhängig von Releasezyklen geändert werden sollen (letzteres ergibt sich aus der Unabhängigkeit der Regeldefinition von der Implementierung der Anwendungssoftware).
Folgendes sind konkrete Anwendungsbeispiele aus der Praxis:
- Einsatz im Call Center: Dem Call Center-Agenten können in Echtzeit in Abhängigkeit von den zu einem Anrufer gespeicherten Informationen Gesprächshinweise angezeigt werden, die dem Agenten helfen, die richtigen Fragen zu stellen und so effizient die nötigen Informationen zu sammeln. Auch können z.B. zu dem Kunden passende Incentives und Up Selling und Cross Selling-Angebote gemacht werden.
- Boni-Berechnung im Autohandel: Ein Automobilhersteller gewährt seinen Händlern bestimmte Boni. Um diese Boni zu berechnen wird Oracle Web Determinations verwendet, wodurch die nötigen Informationen strukturiert abgefragt werden. Zuvor wurde Excel für die Berechnung genutzt, was langwierig und fehleranfällig war.
- Arbeitsvermittlung: Durch die Verwendung der Batch-Verarbeitung von Regeln ist es möglich z.B. passende Bewerber für offene Stellen oder auch offene Stellen zu Bewerbern zu finden.
Praktische Fragestellungen
Abschließend sollen einige typische Fragestellungen aufgeführt und beantwortet werden, die immer wieder vorkommen.
Kann OPA rechnen?
Ja, es können Berechnungen in die Regeln mit integriert werden.
Können die Regeln geschachtelt werden? Können Regeln hierarchisch aufgebaut werden?
Ja, innerhalb einer Regel können „Subregeln“ aufgerufen werden; Ergebnisse einer Regelberechnung können in weiteren Regeln verwendet werden.
Wie ist die Performance?
Sowohl aus unserer Erfahrung heraus als auch gemäß von Oracle durchgeführten Benchmarks kann die Performance als sehr gut angesehen werden. Sofern es einen Engpass gibt, so ist dieser weniger bei der Regelberechnung als vielmehr bei den Web Services zur Übertragung der Daten zu suchen. Sollte dies der Fall sein, ist es eine Überlegung wert, die Batchverarbeitung zu nutzen.
Wie ist die Lernkurve beim Erstellen von Regeln? Wie ist der Einarbeitungsaufwand einzuschätzen?
Die Lernkurve kann allgemein als steil angesehen werden, d.h. nach einer kurzen Einarbeitungszeit können auch Mitarbeiter mit weniger umfassenden IT-Kenntnissen Regeln erstellen.
Wie sieht das Deployment von einer Umgebung auf eine andere aus?
Es muss eine zip-Datei, die durch OPM erstellt wird, auf den Application-Server kopiert werden. Ein Neustart irgendwelcher Komponenten ist nicht notwendig, d.h. es gibt keine Downtime.
Wie ist die Wartbarkeit zu beurteilen?
OPA unterstützt alle gängigen Application Server, so dass es relativ einfach in eine bestehende Landschaft integriert werden kann und die Wartbarkeit daher durch Verwendung bewährter Tools und Methoden gewährleistet ist.
Ist es möglich nachzuvollziehen, wie OPA auf bestimmte Entscheidungen gekommen ist?
Ja, bei Verwendung von Oracle Web Determinations kann der Nutzer direkt über einen Link auf der Oberfläche die Entscheidungsfindung für jede einzelne Regel nachvollziehen. Bei Verwendung des Determinations Servers kann über eine API der Determinations Engine ebenfalls auf diese Informationen zugegriffen werden.
Fazit
Oracle Policy Automation ermöglicht die Erstellung, Pflege und Ausführung von Geschäftsregeln weitgehend unabhängig von der Implementierung der Anwendungssysteme, die diese Regeln benötigen. Dabei ist die Erstellung der Regeln einfach gehalten und schnell zu erlernen. Daher sollte Oracle Policy Automation als eine Möglichkeit der Abbildung und Ausführung von Geschäftsregeln in jedem Fall in Betracht gezogen werden, wenn man es mit komplexen Regeln zu tun hat, die sich häufig ändern und die idealerweise auch noch Releasezyklus-unabhängig geändert werden sollen. OPA kann so helfen, flexibler, schneller und dabei kosteneffizienter auf die Anforderungen des Marktes zu reagieren.
Autor:
Hauke Ehlers
