Finanzinstitute müssen die von ihnen betriebenen Geschäftsaktivitäten verstehen und die damit verbunden Risiken identifizieren, überwachen und steuern. Das gilt auch für Veränderungen, die aus den Geschäfts- und Risikostrategien resultieren. Die „Mindestanforderungen an das Risikomanagement“ (MaRisk) sehen hierfür gemäß AT 8.2 „Änderungen betrieblicher Prozesse oder Strukturen“ einen entsprechenden Anpassungsprozess vor, um die Risiken durch Unkenntnis der Auswirkungen bei Veränderungen in den organisatorischen Strukturen angemessen zu steuern. Um die aufsichtsrechtlichen Mindestvorgaben, Meldepflichten und Rahmenbedingungen zu erfüllen haben die Finanzinstitute entsprechende Regelungen und Prozesse in Form von Organisationsrichtlinien zu implementieren. Bei geplanten „Änderungen betrieblicher Prozesse oder Strukturen“ ist bereits vor der Umsetzung von wesentlichen Änderungen in der Aufbau- und Ablauforganisation sowie in den IT-Systemen eine Auswirkungsanalyse der geplanten Veränderungen durchzuführen. Dabei geht es darum, die Auswirkungen der geplanten Veränderungen auf die Kontrollverfahren und die Kontrollintensität sowie die Funktions- und Wirksamkeit des internen Kontrollsystems (IKS) unter den veränderten Rahmenbedingungen weiterhin sicherzustellen und angemessen auf die Veränderungen der Risikolage zu reagieren.

Die Durchführung dieser Projekte macht ein angemessenes Vorgehensmodell zum Projekt-, Qualitäts- und Changemanagement mit den dazugehörenden Arbeitsmitteln, Gremien sowie Berichts- und Eskalationsverfahren erforderlich. Ohne eine strukturierte, geordnete und nachvollziehbare Vorgehensweise in den einzelnen Projektphasen, wird das Ziel der Veränderungen in dem geplanten Rahmen (Umfang, Qualität, Zeit und Kosten) kaum zu erreichen sein und das Risikoprofil erfahrungsgemäß negativ beeinflussen. Das zeigt sich in der Praxis leider häufig bei den IT-(Software-)Projekten, die vielfach scheitern, das geplante Ziel nur teilweise erreichen oder deutlich mehr zeitlichen Aufwand und Kosten verursachen als ursprünglich geplant.

Geht es beispielsweise um die Durchführung von Software-Migrationsprojekten in einer kundenindividuellen Systemumgebung, also nicht um eine standardisierte Software-Aktualisierung (Release-Wechsel), so sind damit häufig wesentliche Änderungen in den betroffenen IT-Anwendungen und Prozessen verbunden. Das macht eine Umsetzung unter Einhaltung der aufsichtsrechtlichen Anforderungen aus den MaRisk AT 8.2 erforderlich. In der weiteren Betrachtung wird an dieser Stelle nicht näher auf die Änderungen des fachlichen Risikoprofils, die bestehenden Arbeitsabläufe (Prozesse) und die darin integrierten Kontrollaktivitäten, sondern auf das Umsetzungsprojekt eingegangen. Es ist jedoch obligatorisch diese oben genannten Anforderungen entsprechend zu berücksichtigen. Ein ausgereiftes Prozessmanagement, idealerweise eng verknüpft mit dem Management von operationellen Risiken ist hierfür hilfreich und meist unerlässlich. Bei den geplanten Änderungen von betrieblichen Prozessen oder Strukturen resultieren die Risiken im Wesentlichen aus den typischen Projekt- und den Projektumfeld-Risiken.

Die Anforderungen hinsichtlich einer strukturieren, nachvollziehbaren und dokumentierten Vorgehensweise wurden durch die „Bankaufsichtlichen Anforderungen an die IT (BAIT)“ vom 03.11.2017 weiter konkretisiert und der Konsultationsentwurf 04-2018 „Versicherungsaufsichtliche Anforderungen an die IT (VAIT)“ liegt seit dem 13.03.2018 vor. Es sollte dabei jedoch nicht unerwähnt bleiben, dass diese Anforderungen insgesamt nicht neu und bereits seit längerem Bestandteil der etablierten Normen, Standards und Best Practices sind und einer professionellen Vorgehensweise entsprechen.

Unabhängig vom Auslöser und der Art der Veränderung vollziehen sich die Änderungen in der Organisationsstruktur in identischen Phasen, die bei iterativen Verfahren mehrfach durchlaufen werden. Das „Drei-Phasen-Modell“ für Veränderungen untergliedert den Projektablauf in die einzelnen Phasen und liefert die Grobstruktur für das Projekt:

Bei wesentlichen beziehungsweise umfangreichen Änderungen in den Arbeitsabläufen ist es unerlässlich vorab entsprechende Fachkonzepte mit den fachlichen Anforderungen durch die Fachbereiche erstellen zu lassen, was generell obligatorisch sein sollte. Das gelingt jedoch meist nur mit umfangreicher Unterstützung aus dem IT-Anwendungsmanagement und mit Einbeziehung der Fachspezialisten in Form von arbeits- und zeitintensiven Workshops. Wird auf eine vollständige und verständliche Anforderungsspezifikation verzichtet, so besteht ein sehr hohes Risiko, dass die Projekte scheitern beziehungsweise nicht im gewünschten Rahmen (Zeit, Kosten, Umfang und Qualität) umsetzbar sind. Um die Vollständigkeit und Stimmigkeit der Fachkonzepte zu gewährleisten, müssen die Anforderungen aus unterschiedlichen Blickwinkeln und mit Einbeziehung der Governance-Funktionen qualitätsgesichert werden. Dabei sollten auch die realistische Umsetzbarkeit, die Abfolge der Umsetzung und die Abhängigkeiten zu anderen Projekten im Unternehmen beachtet werden. Auf eine Abnahme der Fachkonzepte durch die Fachabteilungen sollte dabei generell nicht verzichtet werden. Das gilt in gleicher Weise für die IT-technischen Konzepte, um eine verlässliche und akzeptierte Basis für die Umsetzung zu schaffen.

Bei der Realisierung eines Software-Migrationsprojekts in einer kundenindividuellen Systemumgebung ist es sehr wichtig, nicht nur den Projektablauf zu strukturieren, sondern auch den Software-entwicklungsprozess mit allen dazugehörigen Phasen als einen integralen Bestandteil des Projektes zu betrachten.

Der Ablauf eines phasenorientierten Softwareentwicklungsprojektes ist nachfolgend schematisch dargestellt:

Das oben genannte Phasenmodell der Softwareentwicklung ist eingebettet in das Projektmanagement. Je nach Umfang, Struktur und Vorgehensmodell im Projekt werden die einzelnen Phasen dabei mehrfach durchlaufen.

Das Testen ist eine wesentliche und umfangreiche Herausforderung, um die Vollständigkeit der Lösungsumsetzung und die fehlerfreie Verarbeitungsfunktionalität zu überprüfen. Diese Aufgaben werden meist in einem eigenen Teilprojekt gebündelt und auf Grundlage eines Testkonzeptes mit den unterschiedlichen Teststufen geplant, bearbeitet, überwacht und gesteuert. Um das Testen transparent und nachvollziehbar zu gestalten, sollten alle Phasen des Testablaufs (Testplanung, -durchführung, -dokumentation, -auswertung und Berichtswesen) in einem Testmanagement-Tool abgebildet werden. Das Abnahmeverfahren anhand definierter Kriterien umfasst alle Teststufen und regelt die Voraussetzungen für den Übergang in die nächste Teststufe und für alle Testdurchläufe. Es ist der Nachweis über die Erfüllung der funktionalen und nichtfunktionalen Anforderungen. Die Testdurchführung erfolgt daher zwingend in separaten Systemumgebungen, die von der Produktivumgebung getrennt sind. Bezüglich der verwendeten Testdaten ist auf die Einhaltung der datenschutzrechtlichen Vorgaben zu achten.

Für den abschließenden Abnahmetest durch den Fachbereich wird meist eine umfassende Testumgebung inklusive aller verbundenen Systeme (Schnittstellen) zur Verfügung gestellt, die sowohl funktional als auch bzgl. ihrer Hardwareausstattung weitestgehend der späteren Produktions-umgebung entspricht.