Mehr Provider, mehr Probleme? Warum Banken ihr Multiprovidermanagement neu erfinden müssen

Die These vieler Banken lautet: „Der Wechsel von einem zentralen IT-Dienstleister in ein Multi-Provider-Modell verspricht Flexibilität, Innovation und geringere Abhängigkeiten.“ Ohne ein neues Steuerungsmodell entsteht jedoch keine größere Freiheit, sondern eine komplexere Form des Kontrollverlusts.

bankon unterstützt Banken und IT-Dienstleister seit vielen Jahren bei der Neuausrichtung ihrer IT, beim Aufbau von Providersteuerung, bei Cloud-Transformationen und bei der Umsetzung regulatorischer Anforderungen.

Im Fokus steht dabei oftmals dieselbe strategische Zielsetzung: Banken wollen ihre Abhängigkeit von einem zentralen IT-Dienstleister reduzieren. Sie wollen flexibler werden, technologische Innovationen schneller nutzen, Kosten verursachungsgerechter steuern und ihre IT-Services differenzierter gestalten.

Die naheliegende Antwort der Banken für diese Zielsetzung lautet häufig: Wir brauchen mehr Provider

Aus Sicht von bankon ist diese Antwort gefährlich und führt nicht zum angestrebten Ziel.

Die erhöhte Flexibilität durch mehr Provider bedeutet für die Bank auch ein komplexes Geflecht gegenseitiger Abhängigkeiten aus

• mehr Schnittstellen,
• mehr Verträgen,
• mehr Zuständigkeiten,
• mehr Abstimmungsbedarf und
• mehr potenziellen Fehlerquellen.

Die Erfahrungen von bankon lassen sich in einer zentralen Aussage zusammenfassen:

Multiprovidermanagement ist die strategische Managementfähigkeit der IT einer Bank

Wesentlich hierfür sind die nachstehenden zehn kritischen Gestaltungserfordernisse

1. Die Providerlandschaft verändert sich – die Bankorganisation oft nicht
   Ein Provider betreibt Teile der Infrastruktur. Ein anderer Provider verantwortet Netzwerke. Cloud-Services kommen von einem oder mehreren Hyperscalern. Cybersecurity-Leistungen werden durch spezialisierte Anbieter ergänzt. Der Anwendungsbetrieb verteilt sich auf interne Einheiten, Softwarehersteller, Managed-Service-Provider und SaaS-Anbieter. Problematisch wird es jedoch, wenn sich die Providerlandschaft deutlich schneller entwickelt als die Steuerungsorganisation der Bank. Für ein komplexes Ökosystem aus Infrastruktur, Plattformen, Anwendungen, Cloud, Netzwerk, Security und Subdienstleistern sind bestehende, historisch gewachsene Governance-Strukturen in der Regel nicht mehr geeignet.
2. Der Kunde kennt keine Providergrenzen
   Der Netzwerkprovider erklärt, seine Verbindung sei verfügbar. Der Cloud-Anbieter verweist auf eine funktionierende Plattform. Der Infrastrukturprovider sieht keine Auffälligkeiten. Der Applikationsbetreiber vermutet die Ursache bei einer vorgelagerten Komponente. Alle Provider können formal recht haben. Der Service ist aus Sicht des Kunden, also der Bank, trotzdem nicht verfügbar. bankon-Experten erleben in der Praxis regelmäßig Situationen, in denen nahezu alle Provider-SLAs „grün“ zeigen, während der Geschäftsservice deutlich beeinträchtigt ist.
3. „Grüne“ Provider-SLAs ergeben noch keinen „grünen“ Bankservice
   Die Bank benötigt deshalb eine klar benannte Ende-zu-Ende-Verantwortung. Entscheidend ist nicht die organisatorische Bezeichnung. Entscheidend ist, dass jemand tatsächlich befugt und in der Lage ist, providerübergreifend zu steuern.
4. ITSM ist das Betriebssystem des Multiprovidermanagements
   ITIL ist eine gute inhaltliche und methodische „Klammer“. Aber, wenn jeder Provider eigene Prioritäten, Statusmodelle, Eskalationsregeln und Toolstrukturen verwendet, entstehen mehrere nebeneinanderliegende ITSM-Welten. Serviceorientierte ITSM-Prozesse dürfen im Multi-Provider-Modell deshalb nicht je Provider gestaltet werden. Sie müssen Ende zu Ende funktionieren. Aus Sicht von bankon ist dabei das Configuration Management besonders kritisch. Wenn nicht transparent ist, welche Anwendungen, Infrastrukturen, Cloud-Ressourcen, Schnittstellen, Datenflüsse und Provider voneinander abhängen, kann die Bank weder Störungen schnell analysieren noch Changes sicher bewerten.
5. Cloud löst Abhängigkeiten nicht automatisch
   Cloud-Plattformen ermöglichen Skalierung, Automatisierung und einen schnellen Zugang zu modernen Technologien. Gerade in den Bereichen Daten, künstliche Intelligenz, Plattformservices und Softwareentwicklung sind sie für Banken kaum noch verzichtbar. Wer jedoch proprietäre Plattformdienste intensiv nutzt, bindet sich technisch eng an einen spezifischen Hyperscaler. Wer Cloud-Ressourcen dezentral bestellt, verliert schnell den Überblick über Kosten, Risiken und Verantwortlichkeiten.
6. Cloud-Einsatz benötigt Rahmenbedingungen
   Je kritischer ein in der Cloud betriebener Service ist, umso bedeutsamer werden klare Schutzbedarfsentscheidungen, definierte Verantwortlichkeiten, transparente Subdienstleisterketten, getestete Backup- und Wiederherstellungsverfahren und realistische Exit- und Migrationsszenarien,
7. DORA zwingt Banken zu mehr Ehrlichkeit
   Die regulatorischen Anforderungen müssen bank- und providerübergreifend unmittelbar mit IT-Betrieb, Security, Architektur, Business Continuity, Einkauf, Recht und Providersteuerung verbunden werden. Ein Provider kann technisch leistungsfähig und wirtschaftlich attraktiv sein. Wenn er jedoch keine belastbaren Nachweise liefert, seine Subdienstleister nicht transparent macht oder die Bank bei Prüfungen, Vorfällen und Exit-Szenarien nicht ausreichend unterstützt, ist er für kritische Bankservices nur eingeschränkt geeignet.
8. Reporting ist lediglich Grundlage einer Steuerung
   Berichte bedeuten nicht automatisch Transparenz. Für eine providerübergreifende Steuerung muss die Bank beispielsweise wissen, wo kritische Abhängigkeiten bestehen, welche wiederkehrenden Incidents nachhaltig gelöst wurden oder welche technischen Schulden das Betriebsrisiko erhöhen. Leistungen, Kosten, Risiken, Architektur und regulatorische Anforderungen müssen mit Unterstützung des Reportings zusammengeführt werden.
9. Auch Financial Operations ist Führungsaufgabe
   In klassischen Outsourcing-Modellen waren Kostenstrukturen häufig relativ stabil und langfristig vertraglich festgelegt. Cloud-Kosten verändern sich dagegen dynamisch mit Nutzung, Architekturentscheidungen, Datenvolumen, Lizenzierung und Verbrauchsverhalten. Eine falsch dimensionierte Umgebung kann innerhalb weniger Monate erhebliche Mehrkosten verursachen. Das Gleiche gilt für nicht abgeschaltete Ressourcen, ineffiziente Speichermodelle oder unnötigen Datenverkehr. Es ist wichtig für die Bank, die Frage zu klären, welcher Geschäftsservice aus welchem Grund welche Kosten verursacht – und ob dieser Verbrauch im Verhältnis zum geschäftlichen Nutzen angemessen ist.
10. Die Bank darf ihre Integrationskompetenz nicht outsourcen
    Besonders in Multiproviderstrukturen darf die Bank bestimmte Kernkompetenzen nicht vollständig abgeben. Beispielhaft seien hier genannt die Architekturhoheit, die Steuerung kritischer Geschäftsservices, das Management des Ende-zu-Ende-Servicemodells oder die Eskalations- und Krisensteuerung.
    Wer die Architektur, die Servicedefinitionen, die Datenmodelle und die wesentlichen Steuerungsinformationen vollständig an externe Dienstleister übergibt, gibt langfristig auch seine Handlungsfähigkeit ab.

Aus der Praxiserfahrung von bankon lautet die entscheidende Leitplanke deshalb:

Provider dürfen Services betreiben. Die Bank muss das Ökosystem beherrschen.

• Es kann einer Bank helfen, die Abhängigkeit von einem dominierenden Provider zu reduzieren und spezialisierte Fähigkeiten gezielter einzusetzen.
• Es kann aber ebenso zu höherer Komplexität, regulatorischen Risiken, unklaren Verantwortlichkeiten und steigenden Steuerungskosten führen.
• Der Unterschied liegt nicht in der Zahl der Dienstleister.
• Der Unterschied liegt in der Reife des Steuerungsmodells.

Deshalb sollten Banken nicht mit der Frage beginnen, welche Leistungen sie an welchen Provider vergeben wollen. Sie sollten zunächst beantworten:

• Welche Verantwortung soll intern verbleiben?
• Wer steuert die Ende-zu-Ende-Services?
• Welche gemeinsamen ITSM-Prozesse gelten?
• Wie werden Cloud, Security und Architektur integriert?
• Wie werden Kosten, Risiken und Leistungen transparent?
• Wie wird ein tatsächlicher Providerwechsel ermöglicht?

Nur unter diesen Rahmenbedingungen ist ein erfolgreiches Multiprovidermanagement möglich. Für die verantwortlichen Entscheider in der IT einer Bank ist die wichtigste Managementaufgabe in der Planung, Konzeption und Umsetzung eines Multiprovidermanagements in folgendem Leitsatz zusammengefasst:

Verantwortung zu delegieren ist nicht ausreichend – das Primat ist die Etablierung und Sicherstellung einer bankeigenen Steuerungsfähigkeit

bankon unterstützt sowohl Banken als auch IT-Dienstleistungsunternehmen in der erfolgreichen prozessualen und technischen Vorbereitung und Umsetzung von Transformationen des IT-Betriebs und der Etablierung von Multiprovider-Strukturen.

Hierbei baut bankon auf seine langjährige Projekt-Expertise in der Planung, Anforderungsspezifikation, Ausschreibung und Umsetzung von Verlagerungen des IT-Betriebs unter Berücksichtigung regulatorischer Anforderungen.

Diese Erfahrung ermöglicht es den bankon-Beratern, gemeinsam mit den Kunden, den am besten geeigneten Weg von der strategischen Entscheidung zur Auslagerung von IT-Betriebsleistungen bis zur Etablierung des neuen Leistungsschnittes zu ermitteln und umzusetzen.

Profitieren Sie von der langjährigen Expertise unserer bankon Berater in der Gestaltung Ihres Multiprovidermanagements. Sprechen Sie uns an.