1 Agilität entscheidet über den Geschäftserfolg
Um unter den heutigen sich schnell ändernden Marktbedingungen erfolgreich zu sein, geraten Unternehmen immer mehr unter Druck, stetig ändernden Anforderungen entgegen treten zu müssen. Dies bedeutet, dass die wertschöpfenden Geschäftsprozesse möglichst flexibel und ohne große Aufwände an die geänderten Strategien adaptiert werden müssen. Betrachtet man solche Veränderungen genauer, lässt sich häufig feststellen, dass die Änderungen meist nicht die eigentliche Struktur eines Geschäftsprozesses berühren, sondern oft nur einzelne Aktivitäten davon betroffen sind. Typische Beispiele finden sich in den Branchen der Finanzdienstleister, Telekommunikation oder auch der öffentlichen Verwaltung. Neue Produkte wie Studentenkredite oder besondere Tarifangebote für Handys unterscheiden sich häufig nur durch spezielle Geschäftsregeln und können durch Integration dieses Konzept sehr schnell auf dem Markt angeboten werden. Darüber hinaus kann der Umsatz in diesen Branchen durch detaillierte Regeln zum Ausschluss möglicher Risiken optimiert werden. Nicht unerheblich sind neben diesen unternehmensspezifischen Geschäftsregeln auch die stetigen Änderungen in den Gesetzesvorgaben, die in den Geschäftsprozessen berücksichtigt werden müssen.
2 Agile Prozesse durch Geschäftsregeln
Betrachtet man sich die zugrunde liegenden Geschäftsprozesse genauer, lässt sich leicht feststellen, dass ein Prozess wie der der Kreditvergabe an sich weitestgehend stabil bleibt. Änderungen schlagen sich meist nur in den Entscheidungspunkten nieder, die eine Aussage darüber treffen, wer diesen Kredit bekommt bzw. welche Konditionen für den Einzelnen angeboten werden können.
 |
 Klicken zum Vergrößern |
| Abb. 1: Prozess mit "grafisch" dargestellter Logik für die Verzweigung |
Mit den bisherigen Methoden zu Prozessbeschreibungen wurden solche Entscheidungen jedoch direkt in die Prozesslogik eingefügt. Anhand von grafischen Modellierungskonstrukten wurde versucht, die Logik, die hinter einer solchen Entscheidung steht, auszuformulieren. Dies mag noch überschaubar sein, wenn es darum geht, Entscheidungen wie ?Ab einer Kredithöhe von 100.000 ? muss der Filialleiter den Kredit genehmigen, ansonsten genügt die Bearbeitung durch den Sachbearbeiter? darzustellen. Die Praxis zeigt jedoch, dass die Entscheidungen meist wesentlich komplexer sind. Prozessbeschreibungen wie in Abb 1 dargestellt sind somit keine Seltenheit.
3 Das Wissen liegt bei dem Prozessverantwortlichen
Die Nachteile einer solchen Beschreibung sind offensichtlich. Kann bei der ersten Modellierung noch eventuell durch viel Gewissenhaftigkeit sicher gestellt werden, dass die Logik korrekt abgebildet ist, so wird spätestens bei der ersten Änderung der Aufwand horrend, um die neue Entscheidungslogik korrekt zu integrieren. Dies hat in der Vergangenheit oft dazu geführt, dass die Logik nur rudimentär oder gar nur als angehängtes Dokument eingefügt wurde. Damit wurde jedoch auf die entscheidende Chance verzichtet, die Qualität der Prozesse zu optimieren und alle geforderte Geschäftslogik adäquat zu erfassen. Es lag damit in der alleinigen Verantwortung des Sachbearbeiters, alle geltenden Regeln bei der Bearbeitung zu berücksichtigen und eventuelle Abhängigkeiten aufzulösen. Sollte eine solche Entscheidung durch ein System automatisiert werden, wurde die Verantwortung an die IT-Abteilung weitergereicht. Diese stand nun vor der Herausforderung, die notwendige Logik aus der unvollständigen Dokumentation zu extrahieren und einen Algorithmus zu entwickeln, der die Entscheidung im Sinne des Unternehmens trifft. Hier war die IT meist überfordert. Gezwungen, auf schlecht dokumentierte Entscheidungsstrategien zurückzugreifen, wurde es meist dem Zufall bzw. dem Engagement der IT-Mitarbeiter überlassen, die gewünschte Entscheidungsfunktionalität korrekt zu implementieren. Wer kann jedoch besser die erforderliche Entscheidungslogik korrekt und vollständig beschreiben, wenn nicht der Prozessverantwortliche selbst.
Um nun nicht in die Falle zu geraten, diese Logik mit den oben beschriebenen Nachteilen im Prozessmodell fest zu verdrahten, muss ein besserer Weg gefunden werden. Ein Blick in die Historie der Anwendungsentwicklung hilft dabei weiter: Während früher jegliche Anwendungslogik in der Applikation fest codiert wurde, ist man bereits früh dazu übergegangen, Programme konfigurierbar und damit leichter anpassbar zu machen. Eine Änderung konnte damit durch eine Anpassung der Konfiguration erreicht werden. Der eigentliche Programmcode musste nicht geändert werden, was auch die sonst notwendige und aufwendige Testphase ersparte.
Diese Entwicklung haben im Laufe der Jahre Applikationen wie Business Rules Anwendungen zur Perfektion gebracht. Durch bereits für den Fachanwender verständliche Beschreibungen der Entscheidungslogik ermöglichen sie, diese vollständig festzuhalten. Durch dahinterliegende Technologien kann diese Logik direkt in Quellcode übersetzt werden. Dabei konnte auf das in der Mathematik bereits bestens bekannte Konzept der Entscheidungstabellen zurückgegriffen werden. Ist das Konzept an sich schon recht anwenderfreundlich, so wurde durch den Siegeszug von Microsoft Excel letztendlich jegliche Hemmschwelle zur Bearbeitung von Tabellen genommen.
 |
| Klicken zum Vergrößern |
| Abb. 2: Regellogik |
Abbildung 2 zeigt, wie die Regellogik aus dem eigentlichen Prozess gelöst wird. Dabei ist es irrelevant, ob die Regel beschreibt, was der nächste Prozesschritt ist, also wie in obigem Fall, wer den Lebensversicherungsantrag als nächsten prüfen muss. Die gleichen Konzepte können auch Anwendung finden, wenn über eine komplexe Logik beschrieben wird, wie die Risikoklasse zu einem Versicherungsantrag bestimmt wird.
4 Wiederverwendung durch Trennung
