Aufrufe
vor 7 Monaten

RISIKO MANAGER 10.2019

  • Text
  • Banken
  • Informationen
  • Beispielsweise
  • Parameter
  • Historical
  • Blockchain
  • Schadenanzahl
  • Unternehmen
  • Risiken
  • Risiko
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.

62

62 RISIKO MANAGER 10|2019 Abb. 03 Struktur einer Cluster-Organisation im Banking Retailgeschäft Kreditgeschäft Handel Transaction Banking Konten Einlagen Filialen Zahlungskarten Krediteinrichtung Kreditüberwachung Kreditservices Risikomanagement Produktportfolio Krediterweiterung Trade- Produkte Prozesse Ratings Asset-/Liability Management Interest Rates, Currency/ Commodity Trading Post Trading Credit Trading Equity System Transfer Trade Finance Payments Mobility Cash Management Channel Banking Regulatorik Services Corporate Platforms Management – Digitization Omnichannel Services Data Market Data Umsatz-Analytics Kosten-Analytics Digital Banking Applications Finance Financial Statements Customer Journey Steuern und Recht Regulatory Financials Reporting Financial Crime, AML & Sanktionen Risikoanalyse Market & Liquidity Market Compliance & Steering Counterpart-Risk Calculations & Reporting/ Risk Models Personal Backoffice Kundendaten Corp. Security & Identity Access Management Customer Data Management Customer Channel Data Governance and Corporate Services Innovationen Agile/Scrum/ Lean Start-up Technology & Innovation Big Data Solutions Technology API / Open Banking Network & Security Infrastructure Cloud Computing Middleware & Environments Predictive Analytics FinTechs eWorkplace Continuous Deployment Operations & Monitoring Ausrichtungen der Bank wie Payments oder Credit Underwriting. Die dritte Kategorie kennzeichnet die Kern-IT-Plattformen und damit Themen wie Cloud, Datenverabeitung, Automatisierung und Omnichannel. Das wesentliche Bindeglied zwischen den Plattformen stellt die sog. Mission Control dar, die wiederum Grundlagen für Design Authority, Governance und Standards legt. Implementierung digitaler Prozessarchitekturen am Beispiel von Magellan Das Magellan-Programm von Deutsche Bank und Postbank hatte 2015 das Ziel, die modernste und leistungsstärkste IT-, Produkt- und Serviceplattform für Bankdienstleistungen im Retail-Banking in Europa zu erstellen. ( Abb. 02) Der Fokus lag dabei auf einer größtmöglichen Flexibilität sowie Skalierbarkeit der IT-Infrastruktur beider Häuser, der Effizienz und Profitabilität durch standardisierte Produkte, verschlankten Prozessen und Systemen (Design-to- Cost; Standardsoftware, Commodity-Infrastruktur-Komponenten) dem Kunden neue Produkte und Dienstleistungen durch den Ausbau der Direktkanäle (konsistentes Multikanalerlebnis) noch schneller grenzüberschreitend anbieten zu können. Dafür bedurfte es einer fortschrittlichen Technologieplattform mit hochmoderner und transparenter IT-Architektur, vereinheitlichter Datenstrukturen, standardisierter Produkte und integrierter Dienstleistungen, sowie im Hinblick auf die Customer Journey vor allem innovativer und einfach bedienbarer Frontend-Tools sowie einer vollautomatisierten Abwicklung im Sinn eines End to End Straight Through Processing (STP) entlang aller Direktkanäle. All dies zudem unter Berücksichtigung einer konsistenten Sicht auf die gesamte Kundenbeziehung bei deutlich erhöhter Datenqualität, flexiblen Angeboten und differenzierten Service-Leveln. Um dies zu erreichen, wurde eine schnelle und sichere Migration auf die Zielplattform sowie eine konsequente Abschaltung der Altsysteme forciert. Eine auf die Postbank und Deutsche Bank fokussierte, innovative, überwiegend

ERM 63 interne IT-Organisation sollte die hohe Effizienz, Innovation und erstklassigen Kundenservice sicherstellen. Involviert waren nahezu alle IT- und fachbezogenen Retailbereiche der Banken, mit dem gemeinsamen Fokus, die Applikationsentwicklung und -pflege auf strategische Applikationen in schlanken und integrierten Entwicklungsprozessen zu konzentrieren. Externe Unterstützung erfolgte seinerzeit durch On- und Near-shore-Anbieter. Der Aufbau und Betrieb der Infrastruktur wurde auf Basis von standardisierten Komponenten aus dem Massenmarkt vorangetrieben. Nicht-Kernkomponenten, wie das Helpdesk und der Enduser-Support, sollten ausgelagert werden. In Abhängigkeit davon, ob die künftige Governance die einer selbstständigen Retailbank ist oder ein Teil der DB AG, sollte eine schlanke COO-Funktion integriert werden, mit dem Ziel, die FOE der Integration künftig zu verantworten. Zur nachhaltigen Prozessoptimierung wurden dazu sechs grundlegende Stoßrichtungen identifziert: » Abläufe verschlanken, bspw. papierhafte Prozesse bei Kontoeröffnungen abschaffen, » manuelle Tätigkeiten einschränken, z. B. Prüfungen bei Kontosperren und Abwicklung vorzeitiger Laufzeitverlängerung automatisieren oder robotisieren, » Prozesse vereinheitlichen, bspw. Sonderkonditionen standardisieren, » die Prozessqualität erhöhen, z. B. die Umgehung „harter“ Sperren automatisiert verhindern, » überflüssige Kontrollen reduzieren, bspw. das Vier-Augen-Prinzip bei keinem bzw. geringem Risiko wie Sparbuchausstellungen abschaffen, » konsequentere Realisierung von Erträgen, bspw. Preiserlässe bei kostenpflichtigen Auskünften abschaffen. Die Sicherstellung des Customer-Journey-Ansatzes und somit einer integrierten Multikanallandschaft für den Kunden basierte im Magellan-Programm auf maximal kanal-, produkt- und serviceübergreifender Prozessstandardisierung, die dennoch den Zugriff auf ein bedarfsgerechtes Produkt- und Serviceangebot ermöglichen sollte. Das heißt, dass alle (abgebrochenen) Vorgänge und Prozesse künftig kanalübergreifend fortzusetzen sind und somit die Abwicklung von Geschäftsvorfällen in Echtzeit ermöglicht wird. Dazu sollten die Mitarbeiter Zugriff auf ein zentrales 360-Grad-Kundenprofil erhalten. Erkenntnisse aus dem Magellan- Projekt Plattform-basierte IT-Architektur-Modelle wie im Beispiel des Magellan-Projekts sollen helfen, den Herausforderungen der Digitalisierung schneller und kundengerechter zu begegnen. Darunter ist keine reine Transformation der IT-Architektur zu verstehen, sondern eine unternehmensweite Veränderung der Plattformausrichtungen in verschiedene unabhängig agierende Einheiten. Diese wiederum müssen entlang der IT-Architektur der Banken effizient gesteuert werden, um nicht nur die digitale Transformation, sondern auch das Innovationsmanagement zu unterstützen. Dabei kann die bestehende IT-Struktur der Banken aufgebrochen und in eine oder durch eine Cluster-Organisation ergänzt bzw. unterstützt werden. Der Vorteil der Cluster-Organisation ( Abb. 03) ist, dass die einzelnen Cluster unabhängig voneinander agieren können. Bildlich lässt es sich so erklären, dass die Cluster viele kleine Schnellboote (bspw. Transaction Banking) sind, die durch eine erhöhte Flexibilität und Unabhängigkeit besser auf Markt- und Kundenanforderungen eingehen können. Allerdings sind diese Schnellboote nicht gänzlich frei in ihren Entscheidungen, sondern hängen immer noch an einem großen Tanker (das sog. Management Digitization). Das bedeutet, wenn alle Schnellboote in verschiedene Richtungen fahren, dann bewegt sich der Tanker nicht vorwärts. Demnach gilt es, den Schnellbooten die Richtung tendenziell vorzugeben und sie nur innerhalb der einzelnen Cluster (bspw. im Kreditgeschäft im Umfeld der Konsumentenkredite) frei agieren zu lassen. Viele Banken deuten das Modell als Micro-Services, was durchaus zu vertreten ist. Jedoch muss die Ganzheitlichkeit des Plattform-Modells hervorgehoben werden, wie es insb. auch im Umfeld des Magellan-Projekts der Deutschen Bank galt. Obwohl das Projekt letztlich gestoppt wurde, lassen sich daraus wichtige Erkenntnisse ableiten. Fazit Die erfolgreiche Transformation der IT-Architektur einer Bank in ein Plattform-basiertes Modell hängt von einer Reihe unterschiedlicher Erfolgsfaktoren ab. Dazu zählen u. a. der Aufbau eines Operational-/ Organisational Change Managements, das Ändern der Denkweise mit Fokus auf User Experience, Design-Thinking, Interoperabilität, Digitalisierung und Automatisierung, das Bilden Plattform-bezogener Teams bestehend aus Fachbereichen, IT und bestimmten funktionalen Skills (Finance, Analytics, etc.) sowie ein Architecture Assessment, also eine Definition der Zielarchitektur (Enterprise und Platform Level), und nicht zuletzt die Entkoppelung und Integration der Plattformen. Autor Dr. Stefan Huch ist Leiter des Bereichs Transaction Excellence bei Capgemini Invent und Vertretungsprofessor für ABWL, Digitalisierung von Geschäftsprozessen an der Hochschule Merseburg. Der Autor dankt Dr. Jan Engel für seine Mithilfe bei der Erstellung dieses Beitrags.

RISIKO MANAGER

RISIKO MANAGER 01.2019
RISIKO MANAGER 02.2019
RISIKO MANAGER 03.2019
RISIKOMANAGER_04.2019
RISIKO MANAGER 05.2019
RISIKO MANAGER 06.2019
RISIKO MANAGER_07.2019
RISIKO MANAGER 08.2019
RISIKO MANAGER 09.2019
RISIKO MANAGER 10.2019
RISIKO MANAGER 01.2018
RISIKO MANAGER 02.2018
RISIKO MANAGER 03.2018
RISIKO MANAGER 04.2018
RISIKO MANAGER 05.2018
RISIKO MANAGER 06.2018
RISIKO MANAGER 07.2018
RISIKO MANAGER 08.2018
RISIKO MANAGER 09.2018
RISIKO MANAGER 10.2018
RISIKO MANAGER 01.2017
RISIKO MANAGER 02.2017
RISIKO MANAGER 03.2017
RISIKO MANAGER 04.2017
RISIKO MANAGER 05.2017
RISIKO MANAGER 06.2017
RISIKO MANAGER 07.2017
RISIKO MANAGER 08.2017
RISIKO MANAGER 09.2017
RISIKO MANAGER 10.2017
RISIKO MANAGER 01.2016
RISIKO MANAGER 02.2016
RISIKO MANAGER 03.2016
RISIKO MANAGER 04.2016
RISIKO MANAGER 05.2016
RISIKO MANAGER 06.2016
RISIKO MANAGER 07.2016
RISIKO MANAGER 08.2016
RISIKO MANAGER 09.2016
RISIKO MANAGER 10.2016
RISIKO MANAGER 01.2015
RISIKO MANAGER 02.2015
RISIKO MANAGER 03.2015
RISIKO MANAGER 04.2015
RISIKO MANAGER 05.2015
RISIKO MANAGER 06.2015
RISIKO MANAGER 07.2015
RISIKO MANAGER 08.2015
RISIKO MANAGER 09.2015
RISIKO MANAGER 10.2015
RISIKO MANAGER 11.2015
RISIKO MANAGER 12.2015
RISIKO MANAGER 13.2015
RISIKO MANAGER 15-16.2015
RISIKO MANAGER 17.2015
RISIKO MANAGER 18.2015
RISIKO MANAGER 19.2015
RISIKO MANAGER 20.2015
RISIKO MANAGER 21.2015
RISIKO MANAGER 22.2015
RISIKO MANAGER 23.2015
RISIKO MANAGER 24.2015
RISIKO MANAGER 25-26.2015
 

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