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