Banken-IT als “Service:” Wie klar ist Ihre Leistungserbringung strukturiert?

Banken-IT als “Service:” Wie klar ist Ihre Leistungserbringung strukturiert?
Inhalt

Warum Banken über Services reden – aber noch in Strukturen der 2000er liefern

Viele Banken sprechen von „Services“, „Serviceorientierung“ oder gar „Servicearchitekturen“.

Doch im Alltag vieler IT-Abteilungen herrscht ein anderes Bild: Leistungserbringung (insbesondere im Projekt-Kontext) ist nicht immer klar geregelt, Verantwortlichkeiten verschwimmen – und die Abstimmungsflut wächst. Was nach fehlenden Verfahren und ungenügender Prozessdisziplin klingt, ist in Wahrheit meist ein Strukturproblem.

Service klingt gut – aber was passiert im Alltag?

Fast alle Banken, mit denen wir arbeiten, investieren viel in ihre IT und deren Aufstellung; das Thema “Service-Orientierung” spielt dabei überall eine zunehmende Rolle.

Allerdings stellen wir – trotz teils erheblich zunehmender Investitionen – immer wieder fest: Pläne und Umsetzung gehen häufig auseinander … und “echte” sowie umfängliche Service-Orientierung bleibt weiter die Ausnahme.

Stattdessen regiert weiter vor allem eines: Die alte, schwerfällige “Silo-Welt:” Produktverantwortliche Abteilungen arbeiten mit dutzenden Systemen – aber haben kaum Einfluss auf Schnittstellen, technische wie fachlicheReibungsverluste sind da selbstverständlich… und die Bremswirkung kann erheblich sein:

Beispiel Zahlungsverkehr: Hier führt die Einführung eines neuen Reporting-Standards gut und gerne zu über 40 Meetings, nur um eine fristgerechte, systemübergreifende Umsetzung sicherzustellen.

Warum? Weil der sogenannte kritische Pfad – eine Verknüpfung mehrerer Systeme, die alle Prozesse oder Workloads einer bestimmten Art nutzen müssen – zwar existiert, aber niemandem gehört. Kein Service-Owner, keine definierten Schnittstellen, keine SLA-basierte Steuerung.

 

Das Ergebnis:

  • Viel Aufwand
  • Wenig Transparenz
  • Keine echte Steuerbarkeit

Was heißt „serviceorientierte“ Bank-IT?

Eine serviceorientierte IT denkt nicht mehr nur in Systemen, sondern in klar definierten Leistungen, die Business und IT gemeinsam verstehen – und die messbar, steuerbar und wiederverwendbar sind sowie ergebnisorientiert erbracht werden.

Konkret heißt das:

  • Ein Service hat ein klar abgegrenztes Leistungsversprechen (z. B. „Zahlungsverkehr abwickeln“ oder „Risk-Scoring fürs Risiko-Dashboard bereitstellen“).
  • Es gibt eine verantwortliche Einheit, die diesen Service steuert.
  • Es existieren messbare Ziele – z. B. Durchsatz, Verfügbarkeit, Bearbeitungszeit.
  • Der Service ist entkoppelt von Einzelanwendungen – kann sich also flexibel an neue Anforderungen anpassen.

Zielbild:

Weniger unkontrollierte Abhängigkeiten, bessere Koordination – dafür mehr Verlässlichkeit, Klarheit und Geschwindigkeit in der Umsetzung.


 

Status quo: Die IT ist modular – aber nicht serviceorientiert

In der Theorie ist der Trend klar: Immer mehr Banken verfolgen serviceorientierte IT-Liefermodelle, modulare Architekturen und Plattformen – schließlich sind die Vorteile überzeugend:

  • Geringere Time-to-Market
  • Bessere Integration
  • Wiederverwendbare Services
  • Mehr Transparenz und Kontrolle

 

In Umfragen, besonders im deutschen Bankensektor, zeigen sich dabei immer wieder fünf klare Zielgrößen: Die Verantwortlichen erwarten vor allem Kostensenkungen,  mehr Flexibilität, erhöhte Skalierbarkeit, bessere Vernetzung bestehender Systeme sowie eine erhöhte Innovationsfähigkeit.

Doch in der Praxis? Bleibt es oft beim Wunschdenken.

 

Serviceorientierung ist kein Tool – sondern ein Kollaborationsmodell!

FINIUS

Die Herausforderungen: Warum Serviceorientierung nicht einfach „passiert“

Der Grund, warum viele Banken an der Serviceorientierung scheitern, liegt nicht in der IT – sondern in der Organisation.

  1. Legacy-Last:
    Die heterogene IT-Landschaft vieler Banken macht Service-Integration komplex, teuer – und riskant.
  2. Schleppende Implementierung:
    Viele Banken, gerade im E-Banking, haben die Service-Orientierung langsamer eingeführt als geplant. Ursachen: zu hohe Integrationskomplexität, fehlendes Change Management, unklare Governance.
  3. Fehlende Steuerung:
    Ohne Service-Governance fehlt der Überblick:
    Welche Services existieren, wo gibt’s Schnittmengen, wer steuert was, wie messen wir Leistung ?
  4. Schwaches Datenmanagement:
    Serviceorientierte IT braucht saubere, nutzbare Daten. Viele Banken haben hier Nachholbedarf – gerade bei personalisierten Angeboten.
  5. Regulatorischer Aufwand:
    Neue Services müssen compliant sein – was Aufwand in Datenschutz, Risiko und Dokumentation erhöht.
  6. Sicherheitsbedenken:
    Mehr Services = größere Angriffsfläche. Ohne gutes Risk Management wird jede Öffnung zum Problem.
  7. Kulturbarrieren:
    Serviceorientierung ist nicht nur Architektur – sondern ein neues Zusammenarbeitsmodell, IT und Fachbereiche zusammenbringt. Und das braucht Zeit, Führung – und klare Zuständigkeiten.

FINIUS 3x: Warum Serviceorientierung Teil der Lösung ist – nicht des Problems

Wir bei FINIUS begegnen diesen Herausforderungen übrigens auf Ebene 3 unseres 3x-Wirkmodells: „Kräfte einsetzen“ – durch serviceorientierte Leistungserbringung.

 

Unser Ansatz:

  • Vermittlung zwischen Fachbereich und IT
  • Balance von Bedarfen und Engpässen
  • Serviceorientiertes Business Modelling
  • Klar definierte, steuerbare Leistungsbausteine
  • Governance-Strukturen, die Verantwortung und KPIs verankern

 

Was das bewirkt:

  • Weniger Abstimmungen
  • Bessere Planbarkeit
  • Schnellere Umsetzung
  • Klarer Ansprechpartner je Service

Wichtig: Serviceorientierung ≠ Toolproblem!

Viele Banken versuchen, das Thema über neue Tools zu lösen: ServiceNow, Atlassian-Suiten, Clarity, Rally, etc.

Doch: Ohne saubere Servicearchitektur – keine Transparenz. Und ohne definierte Leistungsversprechen – keine Steuerbarkeit.

Wir betonen gerade deshalb immer wieder (und wiederholen hier):

☝️ Serviceorientierung ist kein Tool – sondern ein Kollaborationsmodell.

 

Wie also besser werden? Hier unser Vorgehen:

In FINIUS-Projekten Bewährt sich dieses einfache, Dreischrittige Vorgehen immer wieder:

  1. Services identifizieren und definieren:
    Was leistet die Organisation wiederkehrend – fachlich, technisch, organisatorisch?
  2. Verantwortung verankern:
    Wer steuert den Service? Welche Rollen sind kritisch? Wie sehen KPIs und SLAs aus?
  3. Operationalisieren und verankern:
    Wie wird aus Konzepten Leistung? Wie wird Qualität sichergestellt, ohne neue Bürokratie?

Der Effekt:

👉 Business und IT sprechen dieselbe Sprache.
👉 Strategieumsetzung wird konkret.
👉 Innovationen werden skalierbar.

Frage zum Schluss:

Welche internen Services Ihrer Bank-IT sind heute wirklich…

✅ transparent?
✅ steuerbar?
✅ wiederverwendbar?

Wenn die Antwort zögerlich ausfällt, liegt’s vermutlich eben nicht an Methoden und Technik – sondern an der Struktur!

Autoren

Autoren

Dieser Beitrag wurde verfasst von:

Therese Kuhfuß, Director und Leiterin Banken-Team

Martin Koob, Senior Consultant Zahlungsverkehr

Scroll to top