Fiducia & GAD: MaRisk-Risiko beim neuen Kernbanksystem

Banken, die nach dem gerade vollzogenen Zusammenschluss von Fiducia und GAD das Kern­bank­sys­tem zu agree21 migrieren, droht ein MaRisk-Risiko. Der Grund: Viele Institute unterschätzen den Aufwand, zusätzlich zur Umsetzung des IT-Projekts die schriftlich fixierte Ordnung (SfO) zu aktualisieren. Die Bankenaufsicht erwartet diese Anpassungen jedoch bereits wenige Monate nach der erfolgten Systemumstellung.

von Claudia Meier, Procedera Consult

Viele Projektleiter schalten die Orga­ni­sa­tions­abteilungen zu spät ein, wenn es darum geht, das Kernbanksystem auszutauschen und das Organi­sa­tions­handbuch anzupassen.

Kein Wunder: Die zu er­war­ten­den Mehrkosten von bis zu zwei Millionen Euro erscheinen zunächst vernachlässigbar, da das IT-Projekt ein Vielfaches dessen an finanziellem Aufwand bedeutet. Entsprechend budgetieren die Institute den Wechsel eines Kernbanksystems als reines IT-Projekt und sehen die Verantwortung folgerichtig auch auf IT-Seite. Damit die Bankorganisation nicht zu kurz kommt, sollte daher ein SfO-Teilprojekt angelegt werden, um erforderliche Prozessanpassungen von vornherein zu berücksichtigen.

Dies ist umso wichtiger, da viele Banken kaum belastbare Erfahrungen mit der Migration von Kernbanksystemen haben. Das liegt an der Komplexität dieser Systeme und an den hohen Kosten, die sich im Regelfall erst nach mehreren Jahrzehnten amortisiert haben und eine erneute Anpassung rechtfertigen. Viele Projektleiter sowohl auf IT-Seite als auch der Bankorganisation sind also zum ersten oder bestenfalls zweiten Mal mit einem solchen Projekt konfrontiert. Angesichts der hohen IT-Kosten kommen viele Institute zur klassischen Abwicklungsreihenfolge, nach der zuerst die IT-Umstellung erfolgt und dann die nötigen Anpassungen bei der Bankorganisation. Das Risiko besteht darin, die SfO-Anpassung im Organisationshandbuch als reine Fleißarbeit zu unterschätzen.

Best Practice: Pilothandbuch zum Projektstart

In der Praxis hat sich bewährt, die häufig historisch gewachsene SfO bereits weit vor dem Migrationsprojekt zu verschlanken und – falls noch nicht geschehen – auf Prozessorientierung umzustellen. Auf diese Weise lassen sich noch vor dem eigentlichen IT-Projekt sämtliche SfO-Bestandteile, die nicht unmittelbar von der Migration betroffen sind, in einem Pilothandbuch zusammenfassen. Übrig bleibt ein Fundus an Arbeitsanweisungen und Prozessbeschreibungen, die sich während der Migrationsphase nach und nach in das überarbeitete Organisationshandbuch überführen lassen. Das erleichtert die mit dem neuen Kernbanksystem einhergehenden Änderungen an der SfO enorm, zumal die hohen Kosten des Systemwechsels ausschließen, die IT an eine bestehende Prozesslandschaft anzupassen.

Die SfO-Vorstudie lässt sich grob in fünf Einzelschritte unterteilen:

1. Eine Bestandsaufnahme des Organisationshandbuch ermöglicht eine präzise Aufwandsschätzung im Rahmen des Gesamtprojekts sowie die Festlegung von Meilensteinen in Absprache mit den verantwortlichen IT-Leitern.

2. Bereits vor Beginn des IT-Projekts lassen sich OHB- und Prozessmanagement-Tools auf Zukunftsfähigkeit überprüfen und bei Bedarf in einem Atemzug erneuern.

3. Die SfO-Vorstudie legt zudem frühzeitig etwaigen Schulungsbedarf offen, beispielsweise im Bereich Prozessmanagement für die Organisationsmitarbeiter oder in der OHB-Redaktion für die Vereinfachung von Organisationsrichtlinien.

4. Zusätzlich erlaubt eine dem IT-Projekt vorgelagerte Bestandsaufnahme, einzelne Kapital des Organisationshandbuchs vorab nach Überarbeitungswichtigkeit zu sortieren und auf spätere Anwenderfreundlichkeit hin zu überprüfen. Das gilt auch für Regelungen zum Anweisungswesen.

5. Schließlich besteht die Möglichkeit, eventuell bereits vorhandene Revisionsmoniten vor Projektbeginn zu bearbeiten und so zu vermeiden, diese Fehler im Projekt weiter zu vererben.

SfO-Vorstudien bieten darüber hinaus den Vorteil, ermittelte Aufwände bereits vorab in die Verträge mit dem ausgewählten Hersteller des neuen Kernbanksystems mit aufzunehmen. Das schafft zusätzliche Klarheit und erleichtert die Vereinbarung von Meilensteinen und Ergebnistypen während der Umsetzungsphase. Zudem steht bereits vorab fest, zu welchen Zeitpunkten Ressourcen aus anderen Fachbereichen bereitzustellen sind, beispielsweise Spezialisten zum Thema Revision oder Geldwäsche.

BPMN: Erfolg durch bewährte Methoden

Bei einem Wechsel des Kernbanksystems kommt hinzu, dass einzelne Prozesse nicht nur anzupassen, sondern möglicherweise gänzlich neu zu modellieren sind. Im Idealfall haben die Verantwortlichen die SfO-Überarbeitung etwa sechs Monate vor dem eigentlichen IT-Projekt gestartet und erfolgreich auf eine prozessorientierte Betrachtung umgestellt. Dann steht der bekannte BPMN-Methodenbaukasten (Business Process Model and Notation) zur Verfügung, um die neue Prozesslandschaft zu entwickeln und während des IT-Projekts laufend an technische Erfordernisse anzupassen. Ein weiterer Vorteil liegt auf der Hand: Das Institut ist in der Lage, bereits während der Umsetzungsphase gegenüber der Aufsicht nachzuweisen, dass das Organisationshandbuch eine hohe Priorität genießt und in welchem Status sich die ohnehin erforderliche SfO-Aktualisierung derzeit befindet.

Dieses schrittweise Vorgehen – also die SfO-Anpassung im laufenden Projekt, jeweils dann, wenn neue Implementierungsinhalte fertiggestellt sind – bedeutet, die hochkonzentrierte SfO-Erstellung auf die gesamte Projektlaufzeit zu strecken. Erfahrungsgemäß entstehen dadurch keine Mehraufwände gegenüber einer SfO-Umstellung in einem Zug. Vielmehr trägt ein solches Vorgehen zur Planungssicherheit des Gesamtprojekts bei, da bei einem parallel zur Migration durchgeführten SfO-Projekt sämtliche Wissensträger versammelt sind. Das gilt vor allem für Projektleiter auf Herstellerseite, die nach einem erfolgreichen Projektabschluss das Haus verlassen und als Ansprechpartner plötzlich fehlen.

Planungsrisiken ohne SfO-Vorstudie

Eine nachträgliche SfO-Anpassung birgt zudem die Gefahr einer nicht MaRisk-konformen Umsetzung von Arbeitsanweisungen. Dieses Risiko entsteht vor allem durch unzureichende Dokumentationen während des Migrationsprozesses. Häufig fällt das erst auf, wenn die Frage aufkommt, wie die späteren Systemanwender geschult werden sollen. Mit einem bereits vollständig angepassten Organisationshandbuch ist das im Regelfall keine allzu große Herausforderung. Bei fehlenden Dokumentationen dagegen müssen die Verantwortlichen meist in kürzester Zeit ein SfO-Projekt entwickeln und in das bereits laufende Migrationsprojekt integrieren. Das erhöht schlagartig die Zahl an Lieferobjektiven und führt zu Überlastungen vor allem bei Mitarbeitern, die an Schlüsselpositionen im Projekt eingesetzt sind.

Kurzfristig Abhilfe schafft eine Interimslösung, die darin besteht, vom Hersteller bereitgestellte Schulungsunterlagen zum neuen Kernbanksystem in das bestehende Organisationshandbuch zu übernehmen. Doch diese Lösung ist regelmäßig nur von sehr kurzer Dauer. Denn die Übernahme von Herstellerunterlagen in den eigenen Dokumentationsbestand führt erfahrungsgemäß zu Inkonsistenzen, Redundanzen und sogar Widersprüchen. Im schlimmstenfalls drohen in den Folgejahren Revisionsmoniten der Bankenaufsicht, die schließlich eine Grundsanierung des Organisationshandbuch erforderlich machen. Dann stehen die Kollegen aus der Betriebsorganisation häufig allein und unter großem Zeitdruck vor der Aufgabe, das zurückliegende IT-Projekt nachträglich zu verinnerlichen, erforderliche Dokumentationen zu erstellen und die Betriebsanweisungen anzupassen.

Fazit

Eine optimale Migration des Kernbanksystems beginnt mit der Zusammenstellung eines Pilothandbuchs und ermöglicht SfO-Anpassungen im laufenden Projekt. Der dafür erforderliche finanzielle und personelle Aufwand muss von vornherein eingepreist werden, damit das Organisationshandbuch innerhalb kürzester Zeit nach Projektabschluss aktuell ist. Im besten Fall steht der Bankorganisation nach der Umstellung noch ein Zeitraum von zwei Monaten zur Verfügung, um die letzten Änderungen in die SfO einzupflegen. In dieser Zeit finden häufig noch Nacharbeiten an der Software statt, die im Organisationshandbuch ebenfalls zu berücksichtigen sind.aj