Aufrufe
vor 6 Jahren

RISIKO MANAGER 08.2017

  • Text
  • Risiken
  • Risiko
  • Mago
  • Anforderungen
  • Banken
  • Risikomanagement
  • Bafin
  • Risikokultur
  • Unternehmen
  • Risikomanagements
RISIKO MANAGER ist das führende Medium für alle Experten des Financial Risk Managements in Banken, Sparkassen und Versicherungen. Mit Themen aus den Bereichen Kreditrisiko, Marktrisiko, OpRisk, ERM und Regulierung vermittelt RISIKO MANAGER seinen Lesern hochkarätige Einschätzungen und umfassendes Wissen für fortschrittliches Risikomanagement.

14

14 RISIKO MANAGER 08|2017 nehmen wird Excel noch als eigenständiges Controlling-Tool für Planung, Steuerung und Berichtswesen eingesetzt. Da Excel nicht über die Möglichkeiten von Datenbanken verfügt, Daten und Anwendungslogik zu trennen, sind für solche Anwendungen sehr viele umständliche Formelverknüpfungen nötig. Um die in Datenbanken benötigten relationalen Verknüpfungen zu simulieren, werden Verweise neue[r] Tabellenblätter immer mehr mittels SVERWEIS() miteinander verknüpft. Das Ganze resultiert nicht selten in riesengroßen, unüberschaubaren Arbeitsmappen, in denen falsche Verknüpfungen und fehlerhafte Daten nicht mehr kontrollierbar sind.“ [Schels et al. 2014, S. 9] So würden nur kurzfristige Lösungen geschaffen, die weniger nützen als schaden. [Schels et al. 2014, S. 9] Datenanalysen sollten mit den einfachen Mitteln von Excel gelöst werden: „Mit der Programmiersprache VBA lassen sich zwar Makros erstellen, die Prozesse automatisieren und Benutzereingaben im Dialog ermöglichen, in der Praxis fehlen dem Controller aber die dazu zwingend erforderlichen Kenntnisse in Programmierung und Programmorganisation, und die größtenteils per Recorder aufgezeichneten VBA-Makroprozeduren machen die Excel-Lösungen noch kritischer, weil sie sehr wartungsintensiv, intransparent und fehlerträchtig sind.“ [Schels et al. 2014, S. 9] Diese Argumente gelten analog auch für andere Produkte wie die StarBasic-Makros bei LibreOffice oder OpenOffice. „Makroprogrammierung ist nur dann eine nützliche Komponente bei der Erstellung von Controlling-Lösungen, wenn sie von Anfang an von programmiererfahrenen Anwendern für die Automatisierung von Prozessen und für den Benutzerdialog verwendet wird. Auf keinen Fall sollte versucht werden, bestehende Excel-Lösungen mit Makros zu 'retten' oder aufzuwerten. Eine Neustrukturierung, beginnend mit Datenflussplänen und Programmabläufen, ist in jedem Fall vorzuziehen.“ [Schels et al. 2014, S. 10] Eine solche Neustrukturierung im Rahmen von Tabellenkalkulationen, die ohne Makros und damit ohne ihre Risiken auskommt, wird im Rahmen einer einfachen flexiblen Standardisierung aufgezeigt. Berechnungen von Marktpreisrisiken behandeln die möglichen Verluste im Rahmen der Wertänderung von handelbaren Gütern. [vgl. Best 2000, S. 2] Eine einzige korrekte Berechnungsweise für die Risikomessung gibt es nicht, weil die Zukunft unbekannt ist. Wichtiger als die Bereitstellung korrekter Ergebnisse ist bei solchen Kalkulationen die Vermeidung von umständlichen und kostspieligen Prozessen. Daher ist in dem Bereich das Business-IT-Alignment besonders gefragt. Ohne Makros innerhalb von Tabellenkalkulationen braucht ein flexibler Standard zwei Werkzeuge, um das Business-IT-Alignment zu verbessern: Zum einen wird eine Automatisierung auf der Betriebsebene außerhalb der Tabellenkalkulationen vorgeschlagen, zum anderen wird eine standardisierte Dokumentationszeile bzw. -spalte vorgestellt. Die Automation auf Betriebsebene besteht aus Programmen, die optisch aus Benutzersicht standardisiert sind, wie Cmd- Batch, Unix-Bash, Terminal, Automator und Lua. Sie sind flexibler als ausführbare Dateien, denn als Programme können sie schnell editiert und verändert werden. Ihren Ursprung haben sie in der textorientierten Befehlseingabe bzw. Command-Line-Interface (CLI). Sie sind Vorgänger der grafischen Oberflächen oder Graphical-User-Interfaces (GUIs) und wurden von letzteren nicht vollständig ersetzt, sondern bestehen weiterhin parallel. [vgl. Krypczyk et al. 2015, S. 52] „CLI-Systeme hatten auch hier ihre Vorteile: Hatten die Nutzer die Befehle einmal erlernt, konnten sie die Software meist sehr effizient bedienen.“ [Krypczyk et al. 2015, S. 52] Die Schlussfolgerung ist, dass das Paradoxon eines flexiblen Standards mit solchen CLI-Programmen teilweise gelöst werden kann. Ihre Veränderbarkeit und Effizienz können genutzt werden. Innerhalb der Tabellenkalkulationen mangelt es nicht an Flexibilität der Darstellung. Die Vorteile eines flexiblen Standards liegen dort in der Standardisierung durch Einschränkung der Flexibilität begründet. Als einfacher Standard kann eine Zeile zur Dokumentation und Steuerung reserviert werden. Analog zu Datenbanktabellen wird dabei eine Tabellenform mit Spalten, Titel und Daten verwendet. Im Unterschied zur gängigen Darstellung wähle man als Titelzeile nicht die erste, sondern die zweite Zeile. In die erste Zeile schreibe man die Quellenangaben der Inputdaten als Hyperlink, um diese schnell aufzurufen. Kommentare erklären die Formeln im berechneten Datenteil und dienen als Dokumentation der Outputdaten ( Abb. 01). Abb. 01 Flexibler Standard bei Tabellenkalkulation nach Spalten Spalte/ Zeile 1 Pfad/Daten A B C D E F G H I J Anzahl Datensätze 3 Return1 = b_k / b_km1 Return2 = c_k / c_km1 2 Datum Wert 1 Wert 2 Portfolio Gewicht 1 Gewicht 2 Return1 Return2 Return1 gewichtet = g_k * e3 Return1 gewichtet 3 06.06.2017 230 120 1.000.000 30% 70% n.d. n.d. n.d. n.d. Return2 = h_k * f3 Return2 gewichtet 4 07.06.2017 243 110 5,65% -8,33% 1,70% -5,83% 5 08.06.2017 245 123 0,82% 11,82% 0,25% 8,27% 6 … … … … … … …

Marktrisiko 15 Abb. 02 Spalte/ Zeile Flexibler Standard bei Tabellenkalkulation nach Zeilen Als Namenskonvention wird mit _k die k-te Zeile und mit _km1 die Zeile k1 dargestellt. Vorausgesetzt die eingegebenen Formeln entsprechen der Dokumentation, erhält man einen Überblick über die Berechnungen in der Tabelle, ohne die normalerweise versteckten Formeln in den Zellen anschauen zu müssen. Eine Auflistung ist auch in Zeilen möglich. Hier wird die Spalte A als Kommentarspalte für die Input- und Outputdokumentation verwendet ( Abb. 02). Als Namenskonvention wird mit s der Spalten-Buchstabe der jeweiligen Daten (C, D, E usw.) bezeichnet. Flexible Standardisierung lässt sich wie oben beschrieben grundsätzlich bei vielen einfachen bankspezifischen risikoanalytischen Anwendungen realisieren. Eine Ausweitung auf andere Themen innerhalb der Banken und in Unternehmen anderer Branchen ist bei Auswertungen einfacher Datenreihen möglich. Für komplexe Berechnungen zeige ich flexible Standards anhand des Fall-Beispiels einer Value-at-Risk-Kalkulation in einer Bank auf. Value-at-Risk-Berechnungen in Banken als IDV-Anwendung A B C D E F G 1 Pfad/Daten Datum 06.06.2017 07.06.2017 08.06.2017 09.06.2017 12.06.2017 2 Umsatz 12.323 32.123 43.212 12.433 34.231 3 Variable Kosten Die Value-at-Risk-Kalkulation ist eine Messung von Marktpreisrisiken. „Der Value-at- Risk ist festgelegt als Verlustbetrag, der im 9.423 14.123 34.434 12.234 34.564 4 Menge 1.000 6.000 3.000 2.000 1.000 5 Fixe Kosten 15.634 6 Deckungsbeitrag = Umsatz(s_2) - Kosten(s_3) 7 Db pro Stück = s_6 / s_4 8 Gewinn = Summe (C6:G6) - C5 seiner Tabellenblätter kein Datenbankprogramm und nicht für die Verwaltung großer Datenmengen geeignet. Dazu fehlt dem Programm die Fähigkeit, relationale oder multidimensionale Verknüpfungen zwischen Datenpools herzustellen.“ [Schels et al. 2014, S. 7 f.] Eine flexible Standardisierung kann dem Fachbereich kostengünstigere Prozesse und größere Freiräume dadurch erlauben, dass die Nutzung relationaler Datenbanken möglich wird. Dabei ist es nicht nötig, dass ein IT-Tool einer eigenständigen IT-Abteilung sämtliche Aktivitäten des Fachbereichs aus der IT-Landschaft verbannt. [vgl. Schels et al. 2014, S. 13] Es ist sogar geboten, Variationsmöglichkeiten in der Value-at-Risk-Berechnung beim Fachbereich zu belassen. Es handelt sich um Schätzwerte und um die Interpretation der Wahrheit über die zukünftige mögliche Entwicklung von Verlusten. [vgl. Best 2000, S. 81] Bei der von der Aufsicht vorgeschlagenen Trennung von Programm und Daten sowie der Eingabe nur über Formulare und nicht über Tabellen [vgl. Bretz 2013, S. 13 u. 18] ist eine differenzierte Sicht der Dinge wichtig. In einer relationalen Datenbank werden Daten in einer Datei mit Programmen verwaltet, aber die Programme in Form von Abfragen, Views, Makros und VBA-Code sollten stets von Daten frei sein. Formulare können Tabellenform annehmen. Sie sind damit nicht gänzlich etwas anderes als Tabellen. In der Tabellenform kann die Arbeit schneller und übersichtlicher erfolgen. Das erhöht die Datenqualität. Die völlige Loslösung von Daten und Programmen, Formularen und Tabellen in verschiedene Dateien und Prozesse ist nicht mit der Datennachvollziehbarkeit kompatibel, weil von Programmen ganz getrennte Daten nicht umfassend nachvollzogen werden können. Ein flexibler Standard erlaubt durch Archivierung von Daten und Programmen in jeweils versionsgebundenen Dateien auch nach Jahren und bei geändertem Umfeld eine vollständige Nachvollziehbarkeit. Die Anforderungen der Aufsicht können damit widerspruchsfrei erfüllt werden. Auch wenn der Fachbereich allein seine Ziele definiert, ist ein flexibler Standard mit relationalen Datenbanken empfehlenswert. „Eine relationale Datenbank ist eine ausge- Deckungsbeitrag Db pro Stück Gewinn 13.910 2.900 18.000 8.778 199 - 333 2,90 3,00 2,93 0,10 - 0,33 zukünftigen Zeitpunkt … mit vorgegebener Wahrscheinlichkeit … nicht überschritten wird. Dabei ist der historische Verlauf des Portfolios bis zum Zeitpunkt bekannt.“ [Fricke 2007, S. 13] Er ist als komplexer Ansatz der einfachste, der auch von der Aufsicht abgenommen werden kann. [vgl. Hannig 2009, S. 2] Die Aufsicht verlangt allerdings Versioning, Wartbarkeit, Qualitätssicherung, Nachvollziehbarkeit, verständliche Sprache, Trennung von Programm und Daten sowie Überprüfungen bei allen IDV-Anwendungen. [vgl. Bretz 2013, S. 23] „Die besten Regeln werden [jedoch] nicht befolgt, wenn der Arbeitsablauf unbequem und umständlich organisiert ist.“ [Bretz, 2013, S. 24] Allein die Organisation als IDV reicht nicht aus, um einfache Abläufe zu garantieren. Es stellt sich hier die Frage nach dem Business-IT-Alignment, auch wenn die Anforderungen von der Aufsicht kommen. Ein Fachbereich, z. B. Risikoanalyse von Marktpreisrisiken genannt, in einer Bank möchte ferner grundsätzlich einen möglichst umfassenden Überblick über das Marktpreisrisiko haben. Der Vorteil einer IDV-Lösung liegt darin, dass der Fachbereich selbst über die Mitteleinsätze entscheiden kann und auch über diese verfügt. Hierbei wird er durch die verfügbaren Techniken begrenzt. Eine Tabellenkalkulation wie „Excel ist trotz der enormen Größe

RISIKO MANAGER

 

Copyright Risiko Manager © 2004-2017. All Rights Reserved.