Regelwerk

Was Regeln und Entscheidungen zusammenhält und was sie unterscheidet, ist eine oft gestellte Frage, wenn Sowatec zum Thema Business Rules Management berät: Was unterscheidet sie eigentlich genau und welche Abhängigkeiten sind am Werk.
Grundsätzlich lassen sich zu Entscheidungen und ihren Bedingungen drei wesentliche Aussagen treffen.

• Entscheidungen sind von den Prozessen, Systemen bzw. Events strikt zu unterschieden d. h. sie müssen getrennt betrachtet werden. Erst dadurch ist erste ihre Identifizierung und damit Verwaltung möglich.
• Regeln, die für Entscheidungen nötig sind, werden in je nach Ziel bzw. Fokus orientierten Regel”gruppen” zusammengefasst.
• Die Verwaltung eines Regelsets obliegt den Verantwortlichen für die Herkunft der jeweiligen Regeln (Legal, Marketing, Firmenpolitik etc.). Erst wenn Regeln sich ändern, hat das Auswirkungen auf zu treffende Entschedungen, nicht umgekehrt.

Regeln bzw. Business Rules sind also Bedingungen für das Decision Management und seine Werkzeuge, den Decision Services. Bei James Taylor habe ich einen recht guten Artikel zu Decision Services gefunden: Here’s how decisions and rules relate

Neben den Listen am Ende eines Jahres sind die Vorhersagen am Beginn eines neues beliebte Beschäftigung - sowohl in der Unterhaltungsindustrie als auch auf Business-Blogs. Einige davon sind tatsächlich nützlich oder interessant oder beides. - Wie diese Liste, die ich heute kurz zusammenfassen möchte: Was wird 2009 für Business Intelligence bringen (und was womöglich nicht). Das hat Timo Elliott auf seinem BI Question Blog als Umfrage ausgegeben. Die Ergebnisse sind aufschlussreich - und am Ende des Jahres könnte dann innegehalten und die Vorhersage überprüft werden. (Leider geht das dann beim Erstellen der Jahresendlisten immer unter, die Überprüfung der Jahresanfangprognosen).

Nicht weniger interessant ist die Liste der Meinungen, die Timo Elliott aus allen erdenklichen Blogs zum Theme zusammengetragen hat. Das ist eine feine komprimierte Zusammenstellung über Tools und Trends im BI-Zirkus. Aus meiner Sicht trifft James Taylor (Decision Management Blog) den Nagel am besten auf den Kopf. Deshalb zitiere ich hier mal das Zitat:

• Cloud computing will impact decision management
• More use of analytics by systems rather than people
• More focus on rules from application and platform vendors
• More business rule vendors
• More rules in Business Process Management
• Business rules to decision management
• Pre-built decisioning components
• Simulation and scenario management
• More business user control

Seinen vollständigen Artikel kann man auf JT on EDM nachlesen.

weiterlesen »

Im Gegensatz zu gestressten Weihnachtseinkäufern hatte ich in den vergangenen Tagen etwas Zeit - und vor allem Musse - mal ein paar Gedanken zusammenzutragen, warum Business Rules (respektive Business Rules Management = BRM) gerade für die Finanzindustrie so interessant sind. Wichtig auch gerade nach solch dramatischen Entwicklungen wie sie die aktuelle Finanzkrise mit sich bringen.
Die Erhöhung von Marktanteilen ist eher ein schwieriges Unterfangen (ich vernachlässige solche Abwanderungen von Kunden, wie sie die UBS gerade verkraften muss. Da können die anderen Anbieter für kurze Zeit signifikante Erträge über das Neukundengeschäft  generieren.) Noch schwieriger als Marktanteile zu gewinnen, ist der Erhalt der Margen, wie sie noch vor 10 Jahren möglich waren. Sie schmelzen weg wie Eis in der Sonne Spaniens. Und da schliesst sich der Kreis. In Zeiten, in denen die Geschäft wie geschmiert laufen, werden zu hohe Kosten gern vernachlässigt. In Krisenzeiten wird die Reduktion von Komplexität und damit die Senkung von Kosten zum Schlüsselfaktor.

Selten nahmen sich die Verwalter von Finanzprodukten in der Vergangenheit die Zeit, ihre Prozesse auf Effizienz zu trimmen. Jetzt rächt sich dieses Versäumnis. Einsparungspotentiale sollen in Krisenzeiten von jetzt auf gleich umgesetzt werden. Unter diesen Bedingungen entfaltet der Business-Rules-Ansatz seine höchstmöglichen Vorteile. Denn er hilft sehr rasch vor allem jene Umstände anzupacken, die für die ansteigende Komplexität der Geschäftdsregeln und -prozesse in Banken und Versicherungen verantwortlich sind:

• Geschäftsregeln müssen immer häufiger an marktspezifische und/oder staatliche Anforderungen angepasst werden. Die Anforderungen durch Regulierung wachsen stetig und die Zyklen der Anpassungen verkürzen sich
• Die Kundenbedürfnisse werden immer individueller. Immer mehr Kunden bestehen auf speziell zugeschnittene Verträge und Konditionen, deren Verwaltung teure Ressourcen bindet.
• Neue IT-Lösungen führen zu einer technisch spezifizierten Organisation von Prozessen und Geschäftsregeln. Das führt zu spezialisierten “Sprachen” innerhalb der Unternehmensorganisation - das inzwischen bekannte Phänomen  der Kommunikationsprobleme zwischen IT und Business. Hier ist eine Harmonisierung dringend notwendig.
• Mit der technologischen Umsetzung von Geschäftsprozessen nimmt die Redundanz von Geschäftsregeln zu. Denn die meisten Organisationen binden ein und dieselbe Regel oftmals als reduntante Varianten in die unterschiedlichen Prozesse ein. Das verhindert in steigendem Masse die für Agilität und Flexibilität so notwendige Transparenz in Prozessen.
• Auf Grund der IT-orientierten Umsetzung der Geschäftsprozesse ist eine Änderung von Geschäftsregeln sehr ressourcen- und zeitaufwändig. Prozesse können kaum noch zeitnah und marktorientiert angepasst werden.

weiterlesen »

Es gibt Blogeinträge, da ist die Welt nach dem Lesen nicht die gleiche wie davor. - Oder so ähnlich. Jedenfalls hat mir die Lektüre von Carole-Ann zur Entmystifizierung von CEP heute so ein Aha-Erlebnis verschafft. CEP bzw. Complex Event Processing als

ein Themenbereich der Informatik, der sich mit der Erkennung, Analyse, Gruppierung und Verarbeitung voneinander abhängiger Ereignissen (engl. Events) beschäftigt. (wikipedia.de)

Da gab es für mich hin und wieder Fragezeichen, die durch meinen Kopf wanderten. Dank des Artikels sind nun die Unterschiede und Abgrenzungen von Werkzeugen des Prozessmanagements und Business-Rules-Management-Systemen recht deutlich geworden.

Business-Prozessmanagement (BPM) und Business-Rules-Managementsysteme (BRMS) nutzen zwei Arten von Technologien: BRMS-Werkzeuge werden eingesetzt, um Businessverantwortliche ihre Entscheidungen treffen zu lassen. BPM-Tools werden für die Ausführung von Prozessen genutzt, die auf jene Entscheidungen zurückgehen, die ein BRMS-Tool abbildet. So weit, so gut. Als CEP auf den Plan trat, gab es Fragen bezüglich seiner Unterscheidbarkeit zu BPM und BRMS und letztlich seines Einsatzgebietes - oder wie Carol-Ann beschreibt:

When CEP comes into the picture, we feel compelled to question this model.  Is CEP the right technology for processes?  Is it the right technology for decisions?  Some go as far as questioning whether CEP should replace Business Intelligence (BI) and/or Business Activity Monitoring (BAM).

weiterlesen »

Tyner Blain, einer meiner meistgelesenen Blogs, hatte jüngst einen Artikel veröffentlich, der sich mit verborgenen Entscheidungen in Geschäftsprozessen beschäftigte. Sehr erhellend - und wie immer gibt er dazu ein praxisnahes Beispiel.

Er beschreibt ausführlich, dass es sehr sinnvoll sein kann, die definierten Businessprozesse wirklich genau anzusehen und auf verborgene Entscheidungen hin abzuklopfen. Verborgen sind Entscheidungen dann, wenn stillschweigend nur eine Alternative von zwei Möglichkeiten als Prozessschritt ausgewählt wird - ohne die zweite im Prozess auch nur zu erwähnen.
Sein Beispiel: Die Suche nach einem Kunden, die einen automatisierten Prozess einleitet. Drei Möglichkeiten an Resultaten kann es geben:

1. Kein Resultat - ein neuer Kunde wird angelegt.
2. Ein Resultat - der Kunde wird ausgewählt.
3. Mehr als eines bis viele Resultate - ein neuer Kunde wird angelegt.

In diesem Szenario ist natürlich die Variante 3 Anlass für ein genaueres Hinschauen. Warum wird ein neuer Kunde angelegt, wenn es einfach zuviele Resultate hat. Aus Effektivitätsgründen ist in diesem Prozess entschieden worden, keine Zeit beim Selektionsprozess zu verlieren. Dafür werden Dubletten in Kauf genommen, die zu einem späteren Zeitpunkt einfach beglichen werden. Trotzdem ist bei dieser Variante des Prozesses  eine manuelle Intervention nötig. Das heisst, der Prozess wird unterbrochen.

weiterlesen »

Vor einigen Tagen fand ich einen Artikel, der auf sehr anschauliche Weise erklärte, weshalb der Business-Rules-Ansatz so wichtig ist. Es sind immer noch wenige Experten, die von jener Relevanz des Business Rules Managements (BRM) ausgehen. Drei entscheidende Fragen werden sich all jene stellen, die ernsthaft über einen Einsatz von BRM sprich automatisierbaren Geschäftsregeln nachdenken:

1. Was sind die Vorteile von Business Rules, die ein zusätzliches Investment rechtfertigen?
2. Warum sollte man nicht nur die Regeln codieren?
3. Werden die Regeln verlässlich funktionieren und vor allem sich reibungslos in das System integrieren lassen?

Chris Berg von ILOG zählt folgende, knapp zusammengefasste Vorteile für den Einsatz von BRE auf: Verkapselung (technische Separation einzelner Geschäftsvorgänge deren Herauslösung aus dem Software-Code der operativen Systeme), Vereinfachung der Abläufe, Sichtbarkeit der Prozesse, verbesserte Zusammenarbeit und mehr Flexibiltitä durch die verteilte Ausführung. Dieser Zusammenfassung fügt James Taylor in seinem interessanten Blogeintrag noch einige Anmerkungen hinzu, die die Sache noch deutlicher auf den Punkt bringen.

• Die Trennung der Entscheidungslogik von den “mechanischer Umsetzung” gibt dem Business (und seinen Verantwortlichen) endlich ihre Flexibilität für die täglichen Anforderungen zurück. Änderungen in den Geschäftsprozessen haben nur noch geringen bis gar keinen Einfluss auf das IT-System selbst.
• Geschäftsregeln sind im Normalfall für Businessverantwortliche viel verständlicher - es ist quasi ja ihre Alltagssprache. Dieses verbesserte Verständnis hat natürlich Auswirkungen auf die Kommunikation zwischen Business und IT. Es gibt weniger Missverständnisse, die FehliInterpretationen befördern. Alles in allem lassen sich Projekte reibungsloser und ergo schneller umsetzen.
• Geschäftsregeln kann man leicht aufsplitten für verschiedene Gruppen mit einem jeweils anderen Fokus auf das Business. Damit werden auch die Rollen für die einzelnen Geschäftsprozesse transparenter.
• BRM-Systeme führen interaktive Tests und Simulationen im laufenden Betrieb durch, für die Entwicklung und Dokumentation stehen unterstütztend Flussdiagramme, Verweiswerkzeuge und Reporting-Funktionen zur Verfügung
• BRM-Systeme verfügen über vordefinierte Funktionen für den Austausch von Regeln, um Änderungen im laufenden Betrieb, sprich ohne Unterbrechungen durchführen zu können.
• Business Rules sind sehr einfach terminierbar. Sie können sozusagen mit dem Kalender geplant und ausgeführt werden.
• Vorlagen für die Administration der Regeln können die einzelnen Anwender / Owner übersichtlich selbst erstellen, einsehen oder ändern.
• Die Rule Engine - das Kraftwerk eines BRM-Systems - kann aus einer Fülle von Regeln sehr schnell die geeignete, fallbezogene Regel herausfinden.

weiterlesen »

Fand eben ein sehr übersichtliches Schema für die Darstellung von Lebenszyklen bei der Softwareentwicklung - speziell für von uns entwickelten Business-Rules-Solutions. Dafür ist das Netz einfach super - eine dermassen handliches Sheet zu finden, dass man zum nächsten Kundenmeeting mitnehmen kann.

Es vereinfacht zwar die einzelnen Schritte bzw. Entwicklungsphasen drastisch - schon allein das Spezifizieren der Requirements bedarf ja in der Regel mehrerer Interationen. Diese oft sehr komplexe Phase (ist ja klar - danach richtet sich dann alles) - wird hier mal eben auf das unscheinbare “Specifications” runtergebrochen. Aber diese konsequente Reduzierung macht diese Übersicht ja so trefflich übersichtlich. <G> Ziel dieses Schemas ist mit den Worten des Autors

… to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the major work that needs to be done for developing the applications.

Der Agile Ansatz beim Entwickeln von Software hat ja gerade zum Ziel, kurze Iterationen zu erzwingen, damit so schnell wie möglich Businessanforderungen in einsatzfähige Software umgesetzt werden kann.

Zum gesamten Artikel von Jerome Boyer

Ich gebe es zu, Marketingmenschen - vor allem in grösseren Unternehmen - sind heute nicht mehr zu beneiden. Vorbei scheinen die Zeiten, in denen coole Leute hauptsächlich mit interessanten anderen Leuten aus der Designabteilung entspannte Meetings abhalten konnten - mit anschliessenden after hours im Club um die Ecke. Oder war das immer schon eine überspannt falsche Einschätzung?
Jedenfalls scheinen diese rosigen Zeiten für Marketingfachleute vorbei. Denn deren Anforderungen, immer und zu jedem Zeitpunkt die richtigen Kommunikationsinstrumente und -taktiken einzusetzen, steigen exorbitant mit dem Anforderungen durch das Customizing. Und die Erwartungen an den Erfolg der eingesetzten Mittel ebenso. Aber was macht man, wenn während der gesamten Ausbildung das Produkt im Zentrum stand - und jetzt ein Paradigmenwechsel stattfindet? Die Kunden waren zwar schon immer König und Königin. Doch inzwischen scheinen der Worte genug gewechselt - das Marketing wird muss unwiderruflich kundenzentriert werden - in seinem vollumfänglichen Wortsinn. Ein paar Anforderungen zu Erinnerung:

• Wachsender Druck auf die Produktentwicklung, kundenspezifische Lösungen zu entwickeln
• Die Zahl anspruchsvoller Kunden steigt, die erwarten, dass sie und ihre Bedürfnisse dem Unternehmen bekannt sind.
• Zunehmende Restriktionen der Gesetzgeber, wie die klassischen Mittel der Kommunikation angewandt werden dürfen (Richtlinien zu Mailings, Spam, Telefonmarketing etc.)
• Die Entwicklung vor allem bei jüngeren Käufergenerationen, alles sofort verfügbar zu haben. Im angelsächsichen Raum spricht man von einer no waiting culture.
• Steigende Anforderungen von Kundenseite gegenüber Nachhaltigkeit und Umweltverträglichkeit in den Produkten.
• Agile, junge Unternehmen machen es Branchenschwergewichten zunehmend schwer, in diesen schnellen Zeiten angemessen Schritt zu halten. Sie sind mit ihren beweglichen Strukturen meist schneller und reagieren aus der Sicht der Kunden rechtzeitig auf deren Bedürfnisse.

weiterlesen »

Im Juni ist es ja soweit - die diesjährige Konferenz der Business Rules Group findet vom 16.-18. Juni im Münchner Mariott-Hotel statt. Nicht weit weg - das heisst Hingegen.
Im Februar wurden die ersten Previews für das Programm herausgegeben und man darf gespannt auf die tatsächlichen Vorträge sein. Hier eine erste Vorschau:

weiterlesen »

Einen wirklich gutes Summary, wie ein Business Process Management (BPM) aufgebaut werden sollte, habe ich in einem PDF der Butler Group nachlesen können. Und nicht nur das. Im Enterprise Decision Management Blog fand ich dazu auch noch einen lesenswerten Kommentar von dem hier schon häufiger zitierten James Taylor - mit dem recht eindrücklichen Titel Business rules are core to the BPM/SOA value proposition.

Die Butler Group hatte im vergangenen Jahr einen ausführlichen Bericht erstellt, zu dem jetzt ein Management Summary erhältlich ist.

KEY FINDINGS

• Business Process Management (BPM), as a product in its own right, has emerged from the competitive influences of the diverse workflow, integration, and re-engineering camps to deliver solutions that allow the intellect of business users to be a key driver of success.
• During the last two years solutions that operate under the BPM banner have become more functionally inclusive.
• When used to its best advantage, high-calibre BPM provides a systematic approach to improving business and operational processes.
• Cost-saving benefits may provide an initial attraction, but it is product quality and persistent usage that will drive the ongoing benefits of BPM.
• There remains a requirement to address the functional divide between what the BPM software vendors are delivering and what business services users really need from core BPM products.
• A Business Rules Management System (BRMS) approach to development will reduce the inefficiencies that exist within current development methodologies.
• The emergence of rules as a subset of BPM is an indication of the growing maturity of the market.
• Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.
• Butler Group positions SOA and its associated integration services as having a crucial role to play in the BPM service delivery picture.
• Business Activity Monitoring (BAM) promises to keep processes running smoothly, but information overload could end up being counter-productive.
• BPM continues to struggle with standards and their agreed usage. Fundamentally if the sector cannot reach a consensus on the use of headline standards such as Business Process Execution Language (BPEL) and Business Process Modelling Notation (BPMN), there is little chance of it progressing further down the scale.

Zum Management Summary der Butler Group,
Business rules are core to the BPM/SOA value proposition von James Taylor