Der Workflow in der Kreditentscheidung – Herausforderungen und Lösungen mit CAS

Der Kreditentscheidungsprozess unterliegt einem komplexen und in der Regel von Unternehmen zu Unternehmen sehr stark individuell geprägten Workflow. Es gibt eine ganze Reihe von „Leitplanken“, die von aufsichtsrechtlichen Rahmenbedingungen gesetzt werden und sich überall wiederfinden. Die konkrete Ausgestaltung ist aber von den jeweiligen Anforderungen geprägt und nie 1:1 zwischen Kunden übertragbar.

Der Kernworkflow sieht schematisch wie folgt aus:

Kernworkflow
Das ist noch relativ einfach darzustellen und auch in einer Software problemlos abzubilden. Wenn man sich aber jetzt verdeutlicht, welche Randbedingungen sonst noch zu beachten sind und welche Stakeholder an dem Prozess noch mittelbar beteiligt sind, wird es drastisch komplizierter. Hier ein paar prägnante Beispiele:

  • Es existieren häufig mehrere Vertriebskanäle mit unterschiedlichen Anforderungen an Geschwindigkeit und Detailgenauigkeit der Entscheidung
  • Die Regeln für die Berücksichtigung von Berechtigungen und Kompetenzen sind je nach Bandbreite der zu entscheidenden Volumina und Ausgestaltung der Anträge sehr anspruchsvoll umzusetzen
  • Entscheidungen sollen im Mengengeschäft möglichst in Sekunden und ohne menschliche Beteiligung getroffen werden
  • Das Entscheidungssystem soll für mehrere Mandanten unabhängig voneinander nutzbar sein – natürlich mit jeweils eigenen Regeln
  • Die Daten über Entscheidungen sind für sehr viele nachgelagerte Parteien interessant. Als Beispiel seien hier die Revision, die bankaufsichtsrechtlichen Prüfer und damit zusammenhängend auch die Beteiligten an der internen Ratingvalidierung und Kalibrierung genannt. Mit Hilfe der Daten wird dann auch die interne Geschäftspolitik hinterfragt und gegebenenfalls optimiert und angepasst. Alle diese Daten muss das System speichern und bereitstellen, selbst wenn sie für die Entscheidung gar nicht benötigt werden.
  • Das System soll flexibel an neue Anforderungen anpassbar sein

In CAS hatten wir uns diesen Anforderungen zu stellen und haben sehr intensive Überlegungen angestellt, wie dieser komplexe Anforderungskatalog am besten sowohl für den Anwender als auch aus technischer Sicht zu lösen ist. 

Realisierung des Workflows

Um einen flexiblen Workflow abzubilden, gibt es mehrere Möglichkeiten organisatorischer und auch technischer Art, die im Zuge der Entwicklung und im mittlerweile mehrjährigen Einsatz von CAS intensiv beleuchtet wurden. Dabei hat sich ein „Best-Practices-Ansatz“ als Optimum herausgestellt, der durchaus und bewusst von den in der einschlägigen IT-Literatur häufig propagierten Ansätzen abweicht.

CAS nutzt als Oberflächenkonzept einen erweiterten Portalansatz. Als Webanwendung bringt CAS ein vorgangsorientiertes Portal mit, welches wesentliche Erweiterungen zur Unterstützung von workflowbasierten Applikationen und Modulen bietet. CAS selbst ist ebenfalls eine Anwendung, die auf einer Menge von Modulen auf Basis dieser Plattform entwickelt wurde.

Gemeinsam ist allen diesen Modulen, dass sie ihre Oberfläche in Form von einzelnen Fenstern („Portlets“) im Rahmen der Arbeitsfläche darstellen. Ein Workflow im Rahmen dieses Portals wird als Vorgang bezeichnet und unterstützt eine Menge von workflowspezifischen Eigenschaften. 

Hier eine Auswahl:

  • Weiterleitung
  • Bearbeitungsstati
  • Tracking/Zeitmessung der Bearbeitungsschritte
  • Generierung einer Aufgabenliste für den Vorgang

Die Führung des Anwenders durch den Workflow wird durch die höchst flexible Aufgabenliste gewährleistet. Jeder Vorgang und jeder Teilvorgang muss eine individuelle Aufgabenliste bereitstellen. In der Aufgabenliste werden die notwendigen Schritte zur Erfüllung des Workflowteils sowie der Fertigstellungsgrad visualisiert. Auf diese Weise wird der Anwender optimal geführt und kann auf einen Blick ersehen, was zu tun ist. Dies ist besonders bei komplexen Antrags- und Genehmigungsstrukturen ein großer Vorteil.  

Dabei stellt sich die Frage, wie die für eine solche Struktur notwendige Flexibilität am besten erreicht werden kann. Ein Kernpunkt sind dabei eine sehr saubere Trennung der Komponenten und möglichst gut gekapselte Schnittstellen, sowohl intern wie auch (und dort noch viel wichtiger) zu den vielen externen Systemen, mit denen ein Kreditentscheidungssystem kommuniziert. CAS nutzt für die Schnittstellen entweder die EJB-Technologie oder aber Webservices. Den Webservices für externe Systeme ist dann jeweils ein Adapter vorgeschaltet, der die kundenindividuelle Anpassung der externen Daten an die internen CAS Strukturen vornimmt. Auf diese Weise können zum Beispiel unterschiedliche Kundenstammdatensysteme problemlos auch gleichzeitig mit CAS kommunizieren, da sie jeweils einen eigenen Adapter haben, jedoch die interne Struktur in CAS vollkommen identisch bedient wird. Dieses Prinzip ist in CAS durchgehend realisiert.

Ein weiterer Aspekt der Realisierung des Workflows ist das Abbilden von individuellen Regeln und das davon abhängige Ableiten und Modifizieren des Workflows. Um auch hier möglichst flexibel zu sein, werden diese Regeln im Rahmen von CAS in eigenen und mandantenspezifischen Regelwerken abgelegt. Eine Rule-Engine wertet dann jeweils die mandantenindividuellen Regeln aus und ermittelt die Ergebnisse, die dann den Workflow steuern. Mit dieser Technik kann der Programmkern von CAS auch für unterschiedlichste Anforderungen an den Workflow gleich bleiben, die Regeln werden extern in den Regelwerksdateien gehalten und dort verändert. Sie können dann auch mit externen Werkzeugen visualisiert und bei Bedarf auch ohne Programmierkenntnisse modifiziert werden.

Die Realisierung der Workflows in CAS

Im Rahmen der Entwicklung von CAS haben wir uns intensiv mit der Frage auseinander gesetzt, wie sich eine flexible Workflowsteuerung für den Kreditentscheidungsprozess realisieren lässt. Dabei haben wir zunächst die damals verfügbaren Werkzeuge aus dem Bereichen BPEL und BPMN untersucht. Beide Modellierungssprachen erlauben es, Prozesse zu modellieren und die Abläufe in der späteren Softwarelösung entsprechen den Prozessmodellen zu steuern. Dabei ist BPEL deutlich technischer orientiert und vornehmlich zur Steuerung technischer Webservices ausgelegt. BPMN ist stärker fachlich ausgerichtet und verfolgt ausdrücklich das Ziel eine gemeinsame Ebene zwischen Fachabteilung und IT zu schaffen. Eine Umsetzung hätte daher durchaus Vorteile geboten.

Eine tiefer gehende Analyse zeigte jedoch zwei Probleme: zum deckten die damals evaluierten Engines nur einen Teil des definierten BPMN-Standards ab. Die Einschränkungen hätten eine Umsetzung durchaus erschwert.

Weitaus gravierender und letztlich entscheidend war aber die Erkenntnis, dass eine regelbasierte Modellierung der Abläufe in der Kreditentscheidung den Erfordernissen weit eher gerecht wird. Zum einen ist in erstaunlich vielen Fällen die Reihenfolge der Abarbeitung von Aufgaben nicht relevant. Zum anderen bestehen zwischen einzelnen Arbeitsschritten komplexe Zusammenhänge, die nur schwer prozesshaft zu modellieren sind. So wirkt sich beispielsweise das Ergebnis der Sicherheitenbewertung auf den Blankoanteil eines Geschäfts aus, was dazu führen kann, dass ein anderes Rating zu erstellen ist.

Zudem sind viele kritische Entscheidungen fachlich bereits als Regeln formuliert (etwa Kompetenzregeln für die Voten, Ratingregeln für die Auswahl eines zulässigen Ratings, Regeln für die Anwendung des 4-Augen-Prinzips, usw.) Diese Regeln gelten Produkt- und Prozessübergreifend. Bei einer Abbildung in Prozesse würde die Änderung einer Regel, Änderungen in einer Vielzahl von Prozessen erforderlich machen. Zudem wären die eigentlichen Geschäftsregeln nicht nur mehrfach in den unterschiedlichen Prozessen zu definieren – mit allen Risiken von Fehlern und Inkonsistenzen –, die Regeln wären dann höchstens als Erläuterung zum wenig aussagekräftigen Prozessdiagramm ersichtlich.

Für die Umsetzung haben wir daher auf den Einsatz einer Prozess-Engine verzichtet und die Prozesse auf der Grundlage von Geschäftsregeln mit der Rule-Engine des verwendeten JBoss-Application Servers abgebildet.

Perspektive: Die Kreditentscheidung als Serviceleistung

Mit einer flexiblen Architektur wie bei CAS ist es möglich, die Kreditentscheidung auch mit individuellen Merkmalen als zentralisierte Serviceleistung anzubieten.

Gerade bei einer kleinen jährlichen Menge an zu treffenden Kreditentscheidungen lassen sich häufig der Betrieb und die Realisierung einer eigenen Lösung nicht wirtschaftlich darstellen. Mit CAS können wir diese Leistung basierend auf Stückzahlen als externe Dienstleistung anbieten, ohne dabei auf die notwendigen Anbindungen an hauseigene Systeme z.B. des Kundenstamms oder der Rechteverwaltung sowie der Individualisierung des Prozesses zu verzichten. 

Damit ist dann auch bei kleinen Stückzahlen die Abkehr von einem aufwändigen papierbasierten Prozess hin zu einer hoch automatisierbaren und wirtschaftlichen Lösung möglich.

Ansprechpartner: Olaf Port; Turn on Javascript!