„Never change a running system“ wird zum Bumerang
Die Ursachen für diese Gefahren sind den meisten Banken wohl bekannt. Sind doch die IT-Infrastruktur und die Reportingprozesse historisch gewachsen. Oft wurde dabei einer schnellen und kurzfristig kostenminimalen Lösung der Vorzug gegeben, mit der Folge, dass die resultierenden IT- und Reportinglandschaften zu komplexen, teilredundanten Gebilden wurden. Ein Teufelskreis entwickelte sich, da die gestiegene Komplexität noch mehr Argumente für parallele Lösungen geliefert hat, um keine unerwünschten Seiteneffekte von Änderungen zu riskieren. Der integrative Gedanke rückte somit immer weiter in den Hintergrund.
In den meisten Banken hat sich inzwischen die Erkenntnis durchgesetzt, dass ein „Weiter so“ keine Alternative mehr darstellt. Nicht zuletzt die immer weiter steigenden Time-to-Market-Anforderungen lassen sich mit bestehenden Datenarchitekturen nicht oder nur mit unvertretbarem Aufwand umsetzen. Diese These wird auch durch die Ergebnisse einer zeb-Benchmarkanalyse gestützt, wonach im aktuellen Umfeld Banken scheitern, die bestehende und veraltete Datenarchitekturen beibehalten und nur marginal anpassen wollen.
Viele Banken erkennen BCBS #239 als Chance für eine nachhaltige Verbesserung der Datenarchitektur – es mangelt jedoch an Nutzenargumenten.
Angesichts der regulatorischen Anforderungslage aus BCBS #239 und den neuen MaRisk setzen die Banken Umsetzungsprojekte auf. Es hat sich gezeigt, dass es dabei zwei prinzipielle Herangehensweisen gibt: Einige Banken richten das Projekt aus, die regulatorischen Anforderungen mit minimalem Aufwand umzusetzen. Andere Banken starten weitergehende Projekte mit dem Ziel, eine leistungsfähige Datenarchitektur (inklusive Governance und Prozessen) für die gesamte Banksteuerung aufzubauen. Beim weitergehenden Ansatz wird die gesamte dispositive Datenversorgung und -verarbeitung grundlegend umgekrempelt und Aspekte wie der Aufbau eines fachbereichsübergeifenden Glossars, eines fachlichen Datenmodells und in der Folge auch eines integrierten Data-Warehouse für die Banksteuerung (über Regulatory und Risko hinaus) werden angegangen.
Insbesondere im zweiten Szenario gehört ein langer Atem dazu, das gesetzte Zielbild in voller Gänze zu erreichen. Im Wettstreit um Ressourcen in der Bank muss der Projektverantwortliche einerseits durch einen geschickten Releaseschnitt sicherstellen, dass durch das Projekt kurzfristig Nutzen gestiftet wird. Andererseits muss er den Gesamtaufwand des Projekts mit einen Nutzen für die Bank unterlegen. Bei einer Beschränkung des Blicks auf Regulatorik und Risikomanagement (Blick nach hinten: „Wie kann ich Schäden vermeiden?“) tun sich viele Projektleiter schwer damit, eine nachvollziehbare Kosten-Nutzen-Betrachtung aufzustellen.
Machen wir es wie die FinTechs und behandeln Daten als strategisches Asset
Was in dieser Grundhaltung des „Getriebenen“ außer Acht gelassen wird ist, dass man neben der besseren Fähigkeit, die Regulatoren bedienen zu können, mittel- und langfristig die Chance erhält, Daten zu einem strategischen Asset für die Bank zu entwickeln und zur Generierung neuer Erträge zu nutzen (Blick nach vorne: „Wie kann ich neue Erträge generieren?“). FinTechs machen es den traditionellen Häusern vor. Schlanke, datengetriebene Prozesse ermöglichen es, die Ansprüche der Digital Natives besser zu bedienen oder noch drastischer formuliert, neue Ansprüche überhaupt erst zu wecken. Um an dieser Stelle als Bank nicht an Attraktivität gegenüber dem Kunden zu verlieren, bedarf es eines Umdenkens. Studien gehen davon aus, dass bei einem „Weiter so“ die Gewinne der Banken durch den von FinTechs generierten direkten Wettbewerb und Margendruck um bis zu 60 % einbrechen werden.
Große Banken haben die Notwendigkeit des Handelns erkannt und die Position eines CDO geschaffen. Auch werden die Bereiche mit hochkarätigen IT-Experten besetzt (z. B. Deutsche Bank, UniCredit). Neben internen Aktivitäten suchen die Banken bewusst den Kontakt zu den FinTechs. Sie gründen sogenannte Innovations Labs in Innovationszentren wie London oder Sillicon Valley und gehen bewusste Kooperationen mit FinTechs ein. Beispiele für Kooperationen finden sich zahlreich:
- HVB, Comdirect, ING-DiBa mit Gini: Erfassung von Überweisungsdaten durch den Scan von Rechnungsinformationen mit einer Smartphone-Kamera,
- Deutsche Bank, HVB, Apobank, Commerzbank mit Fintura: Konditionsvergleich über Onlineportal für die Mittelstandsfinanzierung,
- UBS, HVB und Sum up: Mobile Payment für Unternehmen mit geringem Transaktionsaufkommen oder den Außendienst,
- DKB und PayPal: Integration von PayPal in das Onlinebanking der DKB. Anziehen von zusätzlichen Kreditkartentransaktionen aus Onlinegeschäften,
- Commerzbank und IDnow: Onlinelegitimation über mobile Geräte innerhalb weniger Minuten.
Der Weg aus der Motivationskrise: Verbindung des Notwendigen mit dem Nützlichen
Ob interne Lösungen der Bank oder Kooperationen mit FinTechs – vor dem Hintergrund der neuen Herausforderungen und Chancen durch die Aktivitäten der FinTechs stellen die Daten der Bank ein zentrales Asset dar. Eine leistungsfähige Datenarchitektur sowie eine hohe Datenqualität sind unabdingbar für die anstehenden Aktivitäten im Wettstreit oder in Kooperation mit den FinTechs. Die regulatorisch angestoßenen Prozesse zur Optimierung der IT-Landschaft sollten also auch vor dem Hintergrund gesehen werden, dass diese dazu dienen, Daten zu einem strategischen Asset auszubauen. In der Kosten-Nutzen-Kalkulation anstehender BCBS #239 oder ähnlich weitgreifender Vorhaben sollten diese Aspekte Berücksichtigung finden, wodurch ein ganz anderer Blick auf den Nutzen dieser Projekte entstehen kann.
