Basel-II-Projekte haben sich in den meisten Unternehmen als weitaus komplizierter herausgestellt als ursprünglich angenommen. Nicht nur die mit dieser Aufgabe üblicherweise betrauten Abteilungen Risikomanagement, Rechnungswesen und IT hatten und haben in diesem Zusammenhang Herausforderungen zu meistern, sondern auch die operativen Abteilungen, beispielsweise Market- und Sales Center sowie das Back-Office. Die Einführung des Basel-II-Akkords in einem Unternehmen lässt sich als ein Transformationsprojekt verstehen, das sich insbesondere dreier Problemfelder annehmen muss. Erstens die hohe Abhängigkeit zwischen Business-Anforderungen und IT-Lösungen, zweitens die Komplexität und Menge der benötigten Daten für die Bildung der Zeitreihen und drittens die Verwendung der gewonnenen Erkenntnisse in der Bankensteuerung und im Risikomanagement.
Hoher Komplexitätsgrad
Die ungewöhnlich hohe Abhängigkeit zwischen Business Anforderungen und IT-Lösungsarchitektur macht es unmöglich, das eine ohne das andere zu entwickeln. Die erste Aktivität im Rahmen von Basel II ist die Frage der Basel-II-Strategie, das heißt die Auswahl der Ansätze, die aber ohne eine grobe Kostenschätzung insbesondere der zu entwickelnden IT-Lösungen, die je nach bestehender IT-Architektur kompliziert und umfangreich ausfallen können, nicht befriedigend beantwortet werden kann. Anschließend müssen die Basel-II-Konsultationspapiere interpretiert und praktische Anforderungen definiert werden. Wie sollte man aber dies ohne eine zumindest rudimentär vorhandene IT- Lösungsarchitektur bewältigen? Es stellt sich somit die Frage nach einer konzeptionellen IT-High-Level-Architektur, die jedoch ohne klare und stabile Business-Anforderungen auch nicht durchgehend spezifiziert werden kann.
Um diese Fragen umfassend beantworten zu können, müssen die Fach- und IT-Abteilungen intensiv zusammenarbeiten. Die gelebte Arbeitsorganisation in vielen Banken ist jedoch auf eine derartig enge Zusammenarbeit nicht vorbereitet. Die IT-Abteilungen, die sich als Service Center verstehen, erwarten die Anforderungen in Form von Fachkonzepten, die die Fachabteilungen nicht sinnvoll erarbeiten können, ohne eine grobe Idee der Lösungsarchitektur zu haben. Hier ist mehr denn je die Rolle der IT als Enabler gefragt, die den Fachabteilungen beratend zur Seite steht und Lösungsalternativen aufzeigt. Die Lösungsarchitektur kann nur gemeinsam erarbeitet werden, da die Anforderungen von Basel II an die Architektur zu weitreichend sind.
Ein weiterer Komplexitätsgrad kommt hinzu, wenn Basel II in einem international operierenden Unternehmen umgesetzt werden muss. Die Autonomie, die einige Filialen oder Tochtergesellschaften genießen, macht es schwierig, eine Gesamtvision für das Risikomanagement und entsprechende IT-Lösungsarchitektur der Bank zu entwickeln und gestaltet die Abstimmung zwischen Business-Anforderungen und IT-Architektur diffiziler. Die Fragen, die in einem internationalen Rahmen zu beantworten sind, beziehen sich auf die zentrale oder dezentrale Risikomodellentwicklung, Validierung und Datenhaltung. Sollen die Risikomodelle zentral entwickelt und validiert werden, bietet sich eine zentrale, granulare Datenhaltung an, die jedoch eine zentrale Organisation der IT und Fachabteilungen für diese Aufgaben voraussetzt. Soll nur das Reporting zentral erfolgen, reichen vereinfacht formuliert, als Schnittstelle zu den Filialen und Tochtergesellschaften die vier Basel Parameter als Input für dieses Reporting.
Gemeinsame und durchgängige Entwicklung
Für die Beantwortung all dieser Fragen ist ein Umdenken sowohl in den Fach- als auch in den IT-Abteilungen notwendig. Ein Projektteam konnte gute Erfahrungen mit Joint-Teams machen, die mit Experten in den jeweiligen Bereichen Alternativlösungen erarbeiteten und erste Kosten-Nutzen-Analysen durchführten. Die Komplexität und Unsicherheit, die mit Basel-II-Projekten einhergeht, kann nur durch einen gemeinsamen iterativen Prozess, der zwischen Fach- und DV-Konzeption nicht völlig trennt, bewältigt werden. Dies darf jedoch nicht als Freibrief für einen chaotischen Projektablauf dienen. Auch hier ist eine Standardvorgehensweise für den Software-Entwicklungsprozess notwendig, die einen geordneten Ablauf, Verifizierung und Versionierung der Ergebnisse garantiert, zum Beispiel Definition der Prozesse für das Change-Request und Anforderungsmanagement.
Die erste Transformation betrifft also vor allem die Kultur und Methoden der Zusammenarbeit zwischen verschiedenen Abteilungen: von einem Abladen der Anforderungen in der jeweils anderen Abteilung zu einer gemeinsamen und durchgängigen Entwicklung.
Zweitens bedingt Basel II, dass Daten aus einer Vielzahl von Legacy-Systemen identifiziert, extrahiert, als Zeitreihen gespeichert und für die Modellentwicklung zur Verfügung gestellt werden. Gleichzeitig laufen in vielen Unternehmen Projekte, gerade diese Systeme abzulösen, was zu Mehrfach- und Parallelarbeit führt. Nicht nur die Basel-II-Implementierung wird langwieriger, sondern auch die Migrationsprojekte, die Mission Critical sind und deshalb in der Regel eine hohe Priorität in den Unternehmen haben.
Datenqualität sicherstellen
Die Frage, wer welche Daten in welcher Qualität sammelt, kann in einem Unternehmen nicht immer erfolgreich beantwortet werden. Sehr oft sind Daten, wie zum Beispiel detaillierte Sicherheiteninformationen oder Cash-Flow-Daten nicht ausreichend oder gar nicht in elektronisch verarbeitbarer Form vorhanden. Diese müssen in Folge erfasst, die erforderlichen Prozesse angepasst und die Mitarbeiter geschult werden. Aber auch wenn die erforderlichen Daten ausfindig gemacht werden können, ist meistens die Datenqualität nicht ausreichend. In einer Welt der unabhängigen Datenhaltungen, die sich in den meisten Unternehmen vorfinden, bestimmen die lokalen Bedürfnisse die Qualität der Daten.
Ein Beispiel für die nicht ausreichende Qualität findet man meistens in den zentralen Geschäftspartnerbeständen, die die Bildung der Kreditnehmer und Kreditnehmereinheiten erschweren. Basel II erfordert aber, diese Daten aus Sicht des gesamten Unternehmens zu kontrollieren, deren Qualität sicherzustellen und die Frage der Data-Ownership zu klären. Unternehmen, die in der Vergangenheit einen zu geringen oder gar keinen Fokus auf Datenqualität und Data-Ownership legten, werden im Zuge der Basel-II-Einführung mit einer Fülle von Problemen konfrontiert werden. Ein robustes Programmmanagement mit ausreichender Unterstützung der Geschäftsführung, das Risiken rechtzeitig erkennt und die richtigen Projekte im Unternehmen initiiert, kann Abhilfe leisten. Zu beachten ist allerdings, dass die Maßnahmen zur Sicherstellung der Datenqualität einen nicht zu unterschätzenden Kostentreiber darstellen.
Die zweite Transformation im Rahmen eines Basel-II-Projektes ist also, die Daten in einem Unternehmen als Aktiva zu sehen und diese auch als solches zu managen.
Verzahnung von Risikosteuerung und Kreditvergabeprozesse
Die Verzahnung von Risikosteuerung und Kreditvergabeprozesse stellt die dritte Transformation dar. Da Basel-II-Regelungen eine Annäherung des regulatorischen und ökonomischen Kapitals anstreben, ist es notwendig, die Erkenntnisse aus den internen Ratingmodellen auch tatsächlich in die Kreditvergabeprozesse und in das Kreditrisikoreporting zu integrieren - falls diese Prozesse nicht frühzeitig an Basel-II-Anforderungen angepasst sind - und somit eine Steuerung des Kreditportfolios nach Risikogesichtspunkten zu ermöglichen. Das bedeutet vor allem ein risikoadjustiertes Pricing und Konditionsgestaltung und adäquates Kreditrisikoreporting. Dieses Vorhaben ist aber in den meisten Unternehmen mit einer umfangreichen Prozessveränderung verbunden. Diese Anpassungen der Geschäftsabläufe können nur mit intensiver Kommunikation mit allen Stakeholdern angegangen werden und setzen im Unternehmen Wille, Zeit und Ressourcen voraus.
Gerade interne Veränderungen gestalten sich in großen Organisationen besonders schwierig. Die Einführung von Basel II in einem Unternehmen kann nur durch ein geeignetes Transformation-Management durchgeführt werden, das auf einer ganzheitlichen Planung beruht und von einem entsprechend qualifizierten Change Manager wahrgenommen wird. Dieser muss ein tiefes Verständnis der Business-Prozesse, der notwendigen Technologie und der Soft-Aspekte des Transformationsprozesses besitzen und diese auch bestens kommunizieren können. COO (Chief Operating Officer) oder CRO (Chief Risk Officer) sind geeignete Stellen, um den Change Manager in ihren Stab aufzunehmen, wo auch gleich das künftige Operating-Modell des Unternehmens festgelegt werden kann.
Einer der wichtigsten Garanten aber für die erfolgreiche Transformation und den kulturellen Wandel ist eine hohe Aufmerksamkeit der Geschäftsführung für diesen Transformationsprozess.