Fusionen und Übernahmen (M&A) und deren Auswirkungen auf Daten

Der Zusammenschluss von Banken und Finanzinstituten stellt deren IT-Infrastruktur und -Anwendungen vor große Herausforderungen. Daher ist es von entscheidender Bedeutung, die Schwierigkeiten anzugehen, die sich aus Fusionen zwischen großen Finanzinstituten mit sich überschneidenden Geschäftsbereichen ergeben, und wirksame Strategien zur Minderung zu finden. Der Schwerpunkt muss darauf liegen, nachzuvollziehen, wie diese Unternehmen die den verschiedenen Anwendungen während der Rationalisierung zugrunde liegenden Daten verwalten, und gleichzeitig zu überlegen, wie die Konsolidierung wertvolle Erkenntnisse liefern kann. Es geht jedoch nicht nur um Datenmanagement. Diese Ereignisse haben weitreichende Auswirkungen sowohl auf interne Anwendungen wie Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) und Human Resource (HR)-Systeme als auch auf externe Anwendungen, die den täglichen Geschäftsbetrieb der Unternehmensbereiche erleichtern.

Bei Fusionen und Übernahmen (M&A) in Banken und Finanzinstituten werden die internen Anwendungen auf eine einheitliche Plattform umgestellt, die beide Unternehmen nutzen. Dieser Prozess kann erhebliche Anpassungen erfordern, um die Funktionalität der einzelnen Systeme zu bewahren. Eine einheitliche Landschaft für alle Interessengruppen zu schaffen kann Monate oder sogar Jahre dauern. In der Zwischenzeit können sich Geschäftsanwendungen unmittelbar auf externe Stakeholder auswirken, was eine sofortige Aufmerksamkeit erfordert. Dieser Artikel befasst sich mit der Integrationsstrategie für Banken und Finanzinstitute und konzentriert sich insbesondere auf die Auswirkungen von Fusionen und Übernahmen auf die Daten der beteiligten Unternehmen.

Inventarisierung aller Anwendungen

Ein wichtiger erster Schritt ist die Inventarisierung aller Anwendungen – eine Tätigkeit, die vielleicht schon vor dem Zusammenschluss teilweise erledigt wurde. Nach einer Fusion oder Übernahme muss das Verfahren jedoch ausgeweitet werden, indem ein zentraler Ausschuss eingesetzt wird, der offenes Feedback zu allen Anwendungen einholt. Dazu gehören Probleme, Herausforderungen, Metriken zum Anwendungsverhalten, Servicequalität und das Finden von Synergien, die zu einem besseren Zielzustand führen als bei einem der beiden involvierten Unternehmen. Die Beteiligung von Enterprise Architecture (EA)-Gruppen ist hier von größter Bedeutung. Das Sammeln korrekter Daten für Anwendungen im gesamten Unternehmen, die nach ähnlichen und sich überschneidenden Funktionen geordnet sind, trägt wesentlich dazu bei, die richtigen EA-Entscheidungen zu treffen.

Flache Integration der Anwendungen

Eine Reihe von Aktivitäten, angefangen bei neuen Logos und dem Re-Branding von Websites, Anwendungsbildschirmen und Berichten, muss möglicherweise unmittelbar nach dem Deal beginnen. Die nächste Welle könnte sich mit einer flachen Integration von Anwendungen mit Benutzeroberflächen, Browsern und mobilen Geräten befassen, die Kunden und anderen Akteuren in der Lieferkette zur Verfügung stehen. Die Konsolidierung und Integration einiger nachgelagerter Anwendungen und Berichte kann für den internen Betrieb notwendig werden. Eine tiefgreifende Integration ist jedoch möglicherweise nicht für alle Anwendungen oder alle Teile davon erforderlich und kann erst in einigen Jahren erreicht werden. Solche Integrationen können architektonische und technische Änderungen erfordern, für die der Return on Investment (ROI) sorgfältig ermittelt werden muss.

Das Backend oder die Serverseite muss für eine flache Integration in eine dreistufige Architektur aufgeteilt werden. Banken haben Mainframes, die schwer zu modifizieren sind. Allerdings gibt es fast immer eine Maske, die vor oder nach der Verarbeitung der Daten im Mainframe sitzt. Beispielsweise kann ein Mainframe-Zahlungssystem in der Finanzabteilung von zwei verteilten Anwendungen in den fusionierten Unternehmen mit normalisierten Daten versorgt werden. Im Gegensatz dazu kann eine browserbasierte Anwendung mit einer darunter liegenden Java-Anwendung interagieren, anstatt direkt mit dem Mainframe.

Bei der „Shallow-Integration“ wird die Verarbeitungsebene in Programmierschnittstellen (APIs) und REST-Diensten (Representational State Transfer) geändert, um dem Kunden eine einheitliche Darstellung zu bieten. Einige davon können tiefgreifende Auswirkungen auf die zugrunde liegenden transaktionalen Anwendungen und Datenmodelle haben.

Transaktionale OLTP-Anwendungen und zugrundeliegende Daten

Transaktionale Anwendungen in Banken sind schwer zu ändern und neigen zu erheblicher Regression – insbesondere bei Legacy-Monolithen. Der ROI einer Änderung von OLTP-Anwendungen (Online Transactional Processing) ist dürftig. Daher kann sich der M&A-Ausschuss für eine oberflächliche Integration entscheiden, die sich auf Mapping-Tabellen und begrenzte Code-Änderungen stützt und den Großteil des zugrundeliegenden Codes im ursprünglichen Zustand belässt. Dies sind keine Notlösungen. Es handelt sich eher um einen integrationsorientierten Ansatz für die serviceorientierte Architektur (SOA). Anwendungen, die Microservices unterstützen, können eine stärker intrinsische Integration erreichen. Es ist jedoch selten, dass sich zwei Anwendungen mit ähnlicher Funktionalität historisch zu Microservices mit genau denselben Domains und einem begrenzten Kontext für jede Domain entwickeln. Solche Chancen werden ziemlich selten sein.

Da OLTP-Anwendungen, -Datenmodelle und -Daten Hand in Hand gehen, würden die meisten Banken davon absehen, viel in die Umgestaltung dieser Systeme an sich zu investieren. Stattdessen sollte sich der EA-Ausschuss mit den niedrig hängenden Früchten der Datenintegration nach dem Transaktionslebenszyklus befassen, d. h. mit den operativen und analytischen Datenspeichern.

Datenspeicher und BigData-Pipelines

Die Zusammenführung und Integration von operativen und analytischen Datenspeichern und BigData-Pipelines ist vor allem deshalb einfacher, weil die Kopplung zwischen den verschiedenen Teilen im Vergleich zu OLTP-Systemen geringer ist und die Latenzanforderungen für jede Operation nicht in der Größenordnung von Millisekunden liegen. Aus demselben Grund sind solche Anwendungen (im Wesentlichen Extrahieren, Transformieren und Laden (ETL) sowie BigData/Machine Learning (ML)-Workloads) und Daten viel besser geeignet, in die Cloud verlagert zu werden.

Nehmen wir also an, dass eine Entität nach der Fusion über einen operativen Datenspeicher (ODS) oder ein Warehouse mit Risiko- und Finanzdaten auf einem On-Premise-Oracle-System verfügt. Und die andere Entität hat ihre Daten kürzlich in ein Cloud Data Warehouse (DWH) auf Snowflake, Redshift, BigQuery oder Azure Synapse migriert. Es wäre sinnvoll, ein Projekt für die erste Entität zu initiieren, um die Daten mit den Werkzeugen und Strategien der zweiten Entität in dieselbe Instanz des DWH zu migrieren.

Verschiedene Teile von Daten oder Anwendungen sind tatsächlich korreliert oder gekoppelt. Allerdings ist die Code-Kopplung (z. B. in verschiedenen ETL-Jobs) weitaus geringer als bei OLTP-Anwendungen, was dies zu einem leicht zu erreichenden Ziel macht. Die Vorteile sind vielfältig. Um nur einige zu nennen: konsolidierte Daten an einem Ort, um Einblicke in das gesamte neue Unternehmen zu gewinnen, neue Berichts- und Business Intelligence (BI)-Standards und die einfachere Einführung eines einzigen Technologiepakets, um die Lizenzkosten und die Anforderungen an die Weiterbildung der Mitarbeiter zu senken.

Die an der M&A beteiligten Entitäten haben möglicherweise zwei verschiedene Cloud-Anbieter gewählt. Auch wenn sich das neue Unternehmen für eine Multi-Cloud entscheidet, ist die Übernahme einer der Clouds für operative und analytische Daten keine allzu große Aufgabe. Die neue Entität kann eine der Instanzen aufgrund bestimmter Faktoren übernehmen: ein modernerer Stack, Datenvolumen, Kosten, Leistung, Kundenzufriedenheit usw.

Migration von Analysedaten: Herausforderungen und Abhilfe

Die Herausforderungen bei der Zusammenführung von zwei Analysesystemen und Datenspeichern aus zwei Unternehmen – und die Lösung – unterscheiden sich im Grunde nicht von der Zusammenführung zweier unterschiedlicher Quellen innerhalb desselben Unternehmens. Dieses Problem ist weit verbreitet und wurde möglicherweise bereits in einer der Data-Lake- oder Warehouse-Implementierungen behoben. Die Erstellung einer Datenzone (oder -stufe) mit konformen Dimensionen ist unerlässlich, indem Mapping-Tabellen und -Lookups verwendet werden, die die Daten standardisieren. Ohne diesen Schritt kann die Analyse zu falschen oder irreführenden Ergebnissen führen.

Der EA-Ausschuss muss eine Rationalisierung der Datenmodelle, Tools, Mechanismen zur gemeinsamen Nutzung und Verteilung von Daten und vor allem aller intern und extern geteilten Berichte vornehmen. Die übliche Strategie besteht darin, eine Sandbox in der Cloud einzurichten, um die ETL-Tools und BigData/ML-Arbeitslasten (in Banken meist Batch-gesteuert) und die neuen Berichte parallel laufen zu lassen, sodass vor dem Wechsel zur neuen Implementierung eine Produktionsparallele erfolgen kann. Die Erstellung eines Datenspeichers mit einem wirklich einheitlichen Datenmodell kann in einem schrittweisen Ansatz erfolgen, aufgeteilt nach Funktionsbereichen und Benutzergruppen.

Wie kann Virtusa helfen?

Die Datenexperten von Virtusa verfügen über umfangreiche Erfahrungen bei der Erstellung von Data Lakes und Data Warehouses, wobei der Schwerpunkt auf cloudbasierten Lösungen liegt. Mit unseren erstklassigen Kompetenzzentren (Centers of Excellence, CoEs) und einem Team von über 1.000 zertifizierten Cloud- und Datenspezialisten verfügen wir über das Fachwissen und die Ressourcen, um die Umsetzung einer einheitlichen Datenarchitektur und -strategie für Ihr fusioniertes Unternehmen zu beschleunigen.

Wir arbeiten eng mit den Geschäfts- und Unternehmensarchitekturteams unserer Kunden zusammen, um die Zusammenführung von Analysedaten zu rationalisieren und dabei unsere umfassende Erfahrung zur Rationalisierung und Optimierung von Datenpraktiken zu nutzen. Unser Ansatz kombiniert Spitzentechnologien wie künstliche Intelligenz und maschinelles Lernen mit den Best Practices der Branche, um eine hochgradig skalierbare und sichere Dateninfrastruktur zu schaffen.

Unser Expertenteam arbeitet mit Unternehmen wie dem Ihren zusammen, um Ihre einzigartigen Geschäftsanforderungen zu verstehen und unsere Lösungen auf Ihre speziellen Bedürfnisse zuzuschneiden. Gehen Sie eine Partnerschaft mit Virtusa ein, denn Virtusa hat nachweislich erfolgreiche Datenprojekte für einige der weltweit führenden Unternehmen durchgeführt.