Liebe Leserinnen und Leser, - BankPraktiker

296
Beitrag
» Der erste Schritt
professionellen
IDV­Anwendungs­
managements
besteht darin, die
wesentlichen IDV­
Anwendungen
anhand der poten­
ziellen Auswirkung
fehlerhafter Pro­
grammqualität zu
identifizieren. «
06 / 2009 BankPraktiker
Der erste Schritt professionellen IDV­Anwendungsmanagements
besteht darin, die wesent­
lichen IDV­Anwendungen anhand der potenziellen
Auswirkung fehlerhafter Programmqualität
zu identifizieren. In der Praxis immer wieder
vorgefundene Kriterien wie die Komplexität der
Programmierung gehen am Ziel eines angemessenen
Risikomanagements vorbei. Eine simple
Addition von 30 Zahlen ist zwar technisch trivial,
doch wenn die Geschäftsleitung auf Basis dieser
Zahlen die Risiken eines Portfolios steuert, muss
sichergestellt sein, dass die Summenformel alle
relevanten Summanden einschließt.
Gängige Kriterien zur Identifizierung wesentlicher
Anwendungen sind:
ß
ß
ß
Werden die Ergebnisse der IDV in bestandsführende
Anwendungen übernommen?
Werden auf Basis der IDV­Anwendung Entscheidungen
erheblicher Tragweite getroffen
(z. B. Fondspreisermittlung, Positionsmanagement,
Kontrollfunktionen im
Risiko­Controlling, Ergebnisermittlung)?
Stellt die IDV­Anwendung die Datenqualität
wesentlicher Anwendungen sicher (z. B.
Abstimmungsanwendungen)
Der Fachbereich hat die wesentlichen IDV­
Anwendungen angemessen zu verwalten. In der
Praxis haben sich einfache Listen bewährt, die
für jede dieser Anwendungen die eingesetzte
Version, Zweck und Zuständigkeiten (Programmierung,
Qualitätssicherung, Test, Abnahme,
Produktiveinsatz) dokumentieren. Die funktionale
Trennung zwischen der Anwendungsentwicklung
und den Qualitätssicherungstests
wird leider in der Praxis regelmäßig vernachlässigt.
Die Analyse zu den wesentlichen Anwendungen
ist im Rahmen der jährlichen Risikoinventur
gem. BTR 4 der MaRisk zu überprüfen.
IV. Die häufigsten Fehler beim
Einsatz von IDV-Anwendungen
und daraus resultierende
Anforderungen
1. Versionierung von
IDV-Anwendungen
Die Nachvollziehbarkeit des Programmcodes
und seiner Versionen ist regelmäßig nicht
sichergestellt. In der Prüfungspraxis ist oft
zu beobachten, dass es nur eine IDV­Anwendungsdatei
gibt, an der immer weiter gebastelt
und die immer wieder überschrieben wird.
Eine preiswerte Abhilfe kann die Nutzung
eines professionellen Versionierungstools (z. B.
CVS) für die Programmdateien und die zugehörige
Dokumentation sein. Auf keinen Fall
darf die Dokumentation älterer Programmversionen
änderbar sein.
2. Trennung von Programm und Daten
IDV­Anwendungen vermischen regelmäßig
Code und Daten. Damit sind die Programmversionen
fix an Datenversionen gekoppelt
und erschweren Kontrolltätigkeiten. Einfach
umzusetzen sind separate Tabellen bzw.
Datenbanken für Datenhaltung, Parametrisierung
sowie für die Funktionalität und
Rechenlogik.
3. Wartung von IDV-Anwendungen
Oft sind IDV­Anwendungen hochindividuell
programmiert und damit schwer oder
gar nicht wartbar (Spaghetti­Code­Risiko).
Dies verhindert eine Entwicklung im Team,
die Nachvollziehbarkeit durch Dritte (Interne
Revision und externe Prüfer) sowie die Unterstützung
durch Spezialisten im Notfall.
Eine wirtschaftliche Weiterentwicklung der
Anwendung anstelle einer Neuentwicklung
wird damit verhindert. Ursächlich ist hier
meist die unzureichende Qualifikation des
Programmierers hinsichtlich professioneller
Anwendungsentwicklung.
Auch bei IDV­Anwendungen müssen Standards
zu Anwendungsarchitektur, Bezeichnung und
Nutzung von Variablen, Objekten und Makros
eingehalten werden. Dokumentationen sind
anzufertigen. Die Einhaltung dieser Standards
ist durch den Fachbereich sicherzustellen.
4. Qualitätssicherung von
IDV-Anwendungen
Vielfach werden IDV­Anwendungen nur durch
den Programmierer selbst getestet bzw. plausibilisiert.
Eine Selbstkontrolle führt regelmäßig
zu keiner angemessenen Anwendungsqualität.
Unabdingbar ist die Kontrolle durch eine weitere
Person, die nicht in die Programmierung
eingebunden war.