Knappe Kassen und immer raschere Veränderungen des Geschäftsumfelds zwingen Unternehmen zu mehr Effizienz unter erschwerten Bedingungen. Einen Ausweg kann unter Umständen Business Rules Management (BRM) bieten, meint etwa die Capgemini sd&m AG, die Technologie-Services-Einheit der Capgemini-Gruppe in den deutschsprachigen Ländern. Geschäftsführer Stefano Trentini formuliert es so: "Der Business-Rules-Ansatz ermöglicht, Expertenwissen aus einzelnen Abteilungen für die ganze Organisation nutzbar zu machen."
Für die gewünschte Effizienz sorgt das BRM-Konzept, indem die IT konsequent an den Bedürfnissen der Fachabteilungen ausgerichtet wird. Die Fachabteilungen formulieren und pflegen selbst mit der technischen Unterstützung durch BRM-Systeme (BRMS) die Geschäftsregeln, denen die IT folgt. Die Geschäftslogik steigt gleichsam aus den Untiefen der Programmcodes hervor und wird transparent. Eine elegante Lösung für das ewige Problem der Reibungsverluste zwischen IT und Business - manchmal zumindest. Was es bei BRM zu beachten gibt, hat der Lösungsanbieter Fico in einem Leitfaden zusammengestellt.
1. Die Wahl der richtigen Lösung: Fico beginnt mit einer expliziten Warnung. BRM-Systeme dienen zur Automatisierung von Entscheidungen. Entsprechend lohnt sich ihr Einsatz nur für System- oder Geschäftsprozesse, in denen einigermaßen häufig wiederholbare Entscheidungen erfolgen. Bei Entscheidungen, die jedes Mal völlig unabhängig zu treffen sind, sei Business Rules Management kaum sinnvoll.
2. Einer Methode folgen: Wer sich für die Arbeit mit Geschäftsregeln und einem BRMS entschieden hat, kann noch lange nicht auf Best Practices in der Systementwicklung verzichten. In diesem Fall sei es sogar besonders wichtig, einer gut durchdachten Methode der Entwicklung zu folgen, meint FICO. Geschäftsregeln seien gut vereinbar mit Methoden wie der Modellierungsmethode Rational Unified Process (RUP) oder dem auf selbst organisierter Teamarbeit setzenden Scrum-Modell.
3. Dokumentation bleibt oberstes Gebot: Ein erster Schritt zur Dokumentation der Anforderungen ist laut Fico die Festlegung von relevanten Geschäftsprozessen, beispielsweise mit Hilfe einer Business Process Map. In die Detailarbeit dringt man anhand von Beispielfällen vor. Diese enthalten Entscheidungen, aber noch keine Geschäftsregeln. Bestimmte Entscheidungen tauchen in mehreren Fällen auf, außerdem werden Abhängigkeiten der Entscheidungen offensichtlich. Auf dieser Grundlage lassen sich Geschäftsregeln entwickeln, die Bedingungen dieser Regeln bestimmen und Regel-Metadaten ableiten, wie die Quelle einer Regel. Die Suche sinnvoller Regeln gehe leichter von der Hand, wenn die Absichten der Business Rules im Entwicklungsumfeld konkret erfasst werden, so Fico. Das kann beispielsweise in einem Word-Dokument oder einer Excel-Tabelle geschehen.
4. Den Ursprung nicht verschwimmen lassen: Falls einmal Änderungen der Business Rules anstehen, ist die Nachvollziehbarkeit ihres Ursprungs grundlegend. Die Basis dafür ist die Dokumentation der Originalquellen. Aufgezeichnet werden sollten alle verfügbaren Quelleninformation - etwa das Gesetz, auf das eine Business Rule zurückgeht, oder die Business Unit, die die Regel aufgestellt hat.
5. Wie immer zählt die Qualität: Die Qualität kann grundsätzlich nach einer Reihe von Kriterien gemessen und entsprechend gepflegt werden. Fico empfiehlt zwei Maßstäbe. Zum einen sollten die Regeln prägnant sein - also keine überflüssigen Bedingungen enthalten. Zum anderen sollten sie "atomisch" aufgebaut sein, was so kleinteilig wie möglich meint. So gilt es zum Beispiel, nicht alle Vorzüge für Premium-Kunden in eine Regel zu pferchen. Möglichst jede Sonderbehandlung bedarf explizit einer eigenen Regel. Das erhöht die Verständlichkeit und Handhabbarkeit der Regeln, wenn einzelne Punkte verändert werden.
6. Anpassung auf mehreren Wegen: Damit die Regeln immer den aktuellen Anforderungen entsprechen, müssen sie von den Usern angepasst werden. Eine der ersten kritischen Entscheidungen ist jene, wer im Unternehmen die Regeln auf welche Weise verändern kann. Unterstützung für verschiedene Grade der Autorisierung sollte ein BRMS in jedem Fall bieten, so Fico. Statt des einfachen "Wenn …, dann …"-Schemas eignen sich auch Entscheidungstabellen als Instrument der Regel-Anpassung. Auf diese Weise kann beispielsweise eine Bank das Kreditlimit für verschiedene Einkommensgruppen ohne Umstände verändern.
7. Verifizierung der Business Rules: Sobald die Geschäftsregeln aufgestellt sind, sollten sie auf strukturelle Probleme - unter anderem sich widersprechende Inhalte - abgeklopft werden. Weil das händisch nur recht mühselig zu leisten ist, rät Fico zu einem BRMS, das die Überprüfung automatisch durchführt.
8. Die Regeln im Lackmustest: Jetzt gilt es festzustellen, ob die Business Rules wie erwartet funktionieren. Ebenso gilt es ständig zu überprüfen, ob Regelanpassungen möglicherweise die ursprünglich beabsichtigte Entscheidung torpedieren. Dazu sind fortlaufende Tests nötig - sowohl für bestimmte Regel-Sets als auch für das System von Regeln als Ganzes.
9. Den Business Impact simulieren: Auch wenn nun alles wie gewünscht zu laufen scheint, stehen die Auswirkung der Business Rules auf das Geschäftsergebnis in den Sternen. Fico empfiehlt daher, bei der Wahl des BRMS auf die Funktion einer Entscheidungssimulation zu achten. Dadurch wird der Einfluss der Regeln aufs Geschäft transparent.
10. Datenpflege durch ein Repository: Ein BRMS lohnt sich erst dann, wenn es wirklich genutzt wird und die Zahl der eingepflegten Regeln steigt. Unersetzlich ist dafür eine Ablage, in der die Regeln gespeichert werden. Dieses Repository muss für den ständigen Gebrauch und für Governance-Anforderungen strukturiert sein. Das heißt, dass das Design der Ablage die Governance Policies unterstützen muss.
11. Zukunftsprognosen einbauen: Geschäftsregeln definieren Entscheidungen. Aber richtig klug werden sie laut Fico erst dann, wenn auch prognostische Analysen berücksichtigt werden. Inzwischen sei es in BRM-Systemen durchaus möglich, Zukunftsszenarien zeitnah mit Produktionsanwendungen zu verknüpfen.