Liebe Leserinnen und Leser, - BankPraktiker

298
Beitrag
06 / 2009 BankPraktiker
dung, weil er sie selbst verwendet. Doch was
ist mit den Aspekten Wartbarkeit, Prüfbarkeit,
Nachvollziehbarkeit, Urlaubsvertretung?
Praktisch reduziert bereits die Einhaltung von
Programmierstandards den Dokumentationsaufwand
erheblich. Die Dokumentation zur
Anwendungsarchitektur enthält Datenquellen,
einen Überblick zur Programmlogik und die
Ergebnisse der Anwendung. Die technische Programmdokumentation
kann auch im Quellcode
durch ausführliche Kommentare stattfinden,
die mit den jeweiligen Anwendungsversionen
abgelegt werden. Das Anwenderhandbuch
kann auch in eine Arbeitsablaufbeschreibung
eingebunden sein; bei größeren Anwendungen
wird oft ein separates Benutzerhandbuch mit
den jeweiligen Anwendungsversionen erstellt.
10. Revision von IDV-Anwendungen
Manchmal werden die IDV­Anwendungen von
der Internen Revision stiefmütterlich behandelt;
die qualifizierte IT­Revision wird im Fachbereich
nicht eingesetzt und die Fachrevision
ist nicht in jedem Fall ausreichend kompetent
für die Aspekte der IDV. Kernpunkt ist hier die
klare Regelung der Zuständigkeit. Hier könnten
gemischte Teams aus Fach­ und IT­Revision
Abhilfe schaffen.
prAXIsTIpps
•
•
•
•
V. Ausblick
Auch wenn dieser Beitrag die Risiken aus
IDV­Anwendungen in den Vordergrund
rückt, soll nicht der Eindruck entstehen, als
seien diese aus dem betrieblichen Alltag zu
eliminieren.
Im Rahmen der Unterstützung bankfachlicher
Prozesse bieten sie erhebliche möglichkeiten
im prototyping. Oftmals kann ein
Fachkonzept für eine (IDV­)Anwendung erst
dann erstellt werden, nachdem mit einem
IDV­Prototyp die Kernfunktionalität entwickelt
wurde. In dieser frühen Phase sind IDV­
Anwendungen durch ihre Flexibilität und
ihre umfassenden Möglichkeiten unschlagbar.
Ebenso sind IDV­Anwendungen vorteilhaft,
wenn es um die rasche unkomplizierte
Filterung, Analyse und präsentation
von Daten aus bestandsführenden Anwendungen
geht.
Wesentlich ist, dass die Risiken aus dem
Einsatz von IDV­Anwendungen qualifiziert
gegen die Chancen ihrer Nutzung abgewogen
werden. Nur dann werden operationelle
Risiken den Vorschriften des BTR 4
Rdn. 2 der MaRisk entsprechend identifiziert
und beurteilt. £
Qualifizieren Sie Fachbereichsmitarbeiter nicht nur hinsichtlich der technischen
Möglichkeiten von z. B. Excel und Access, sondern auch hinsichtlich angemessener
Anwendungsentwicklungsprozesse.
Ermitteln Sie die in Ihrem Haus eingesetzten wesentlichen IDV­Anwendungen.
Dies sind erfahrungsgemäß mehr als fünf, aber weniger als fünfzig.
Analysieren Sie die operationellen Risiken aus diesen wesentlichen IDV­Anwendungen
systematisch und dokumentieren Sie die Chance­Risiko­Abwägung.
Lassen Sie die Restrisiken durch einen geeigneten Kompetenzträger wie Abteilungsleiter,
Fachbereichsleiter oder die Geschäftsleitung gegenzeichnen.