Bonitätsprüfungen müssen vor allem zwei Eigenschaften haben: Zuverlässigkeit und Geschwindigkeit. Hat der Kunde seine Kreditanfrage gestellt, beginnen im Hintergrund die Algorithmen zu rechnen. Bislang gab es für die verschiedenen Kreditanlässe meist eine eigene Methode. Auf Kosten der Nachvollziehbarkeit für eine übergeordnete Stelle wie die Bankenaufsicht. Daher die Ansage: Wir brauchen Einheitlichkeit. Gleichzeitig müssen jedoch Flexibilität in der Parametrisierung und Datentrennung der einzelnen Institute gegeben bleiben. Klingt nach einer detailreichen und kniffligen Herausforderung. Sven Mares, Bereichsleiter Software Engineering bei ITGAIN, war dabei.
Mares: „Wir kennen uns im Rechenzentrum aus und wussten, was auf uns zukommt. Eine realistische Kosten- und Zeitplanung vorab war zügig erstellt. Wir konnten dann direkt eine Festpreisprojekt anbieten.“
Lief es dann auch so reibungslos wie erwartet?
Mares: „Alle Banken unter einen Hut zu kriegen war schon nicht einfach. Doch die fachlichen Vorgaben des Verbandes waren klar und gut strukturiert. Wir haben daraufhin ein modulares System entwickelt, das uns maximalen Spielraum für kurzfristige Änderungswünsche gegeben hat.“
Wo lagen die Knackpunkte?
Mares: „Da bislang keine einheitliche Methode vorlag, gab es auch keinen einheitlichen Anforderungskatalog für die Kreditkunden. Beispiel: Während für den einen Kreditanlass wichtig war, wie lange der Kunde verheiratet war, war für einen anderen Kreditanlass nur relevant, ob er überhaupt eine Ehe eingegangen ist. Es musste also geklärt werden, was in den einheitlichen Katalog kommt und was nicht. Im Fokus standen dabei ganz klar die fachlichen Anforderungen der Kunden. Wir analysierten zudem die bestehende IT-Architektur und gaben Empfehlungen, wie sich die neue Infrastruktur gestalten lässt.
Klassisches Architektur-Management also. Auf diese Analyse mit dem Verband folgte eine recht umfangreiche Recherchearbeit im Rechenzentrum. Denn aus den technischen Systemen mussten die fachlichen Kennzahlen ermittelt und historisiert werden.“
Was zeichnet die neue einheitliche Methode aus?
Mares: „Wir haben eine Anwendung entwickelt, die einerseits dezentral auf JavaEE basiert und andererseits auf dem Mainframe-Host die Batchkomponenten bedient. Das heißt jede Bank kann weiterhin ohne Probleme ihre monatliche Prüfung der bestehenden Kunden durchführen. Sie kann aber gleichzeitig eine Einzelprüfung fahren, wenn der Kunde die Filiale betritt und nach einem Kredit fragt. Das alles steuert eine zentrale Architektur. Eine fehlerhafte Doppelentwicklung wurde vermieden. “
Was ändert sich für die Anwender?
Mares: „Im großen Ganzen merken sie keinen Unterschied. Alles bleibt so zuverlässig wie früher und genauso schnell.
Uns war es besonders wichtig, die Anwender vom ersten bis zum letzten Tag im Boot zu haben. Sie sollten wissen, was wir tun, warum wir es tun. Es wichtig bei solch großen Projekten den Weg gemeinsam zu gehen."
SVEN MARES- BEREICHSLEITER SOFTWARE ENGINEERING
Was die Benutzung angeht, haben wir ein detaillierte Verfahrensbeschreibungen und weitere Dokumenationen für die Kunden verfasst - etwas mehr als nur ein Handbuch sind für die Prüfungen durch die Aufsicht nötig. An das Projekt schloss sich außerdem ein Wartungsdienst an, den wir nochmal ausgiebig genutzt haben, um den Anwendern alle Fragen zu beantworten. Das ist der Vorteil, wenn ein solches Projekt komplett aus einer Hand kommt, wir können dann direkt unterstützend zur Seite stehen.“