Stell dir vor, du hast sechs Monate lang an einer neuen Schnittstelle gearbeitet, die den Kreditprozess für Firmenkunden in den Sparkassen revolutionieren soll. Du hast die Architektur sauber geplant, die Sprints liefen gut durch und dein Team ist stolz auf den Code. Am Tag der Pilotierung in einer mittelgroßen Sparkasse passiert dann das, was ich schon dutzende Male erlebt habe: Der Berater vor Ort öffnet die Anwendung, starrt drei Sekunden auf den Bildschirm und sagt, dass er so nicht arbeiten kann, weil die Datenvalidierung nicht zu den internen Kompetenzrichtlinien seines Hauses passt. In diesem Moment realisierst du, dass du zehntausende Euro und hunderte Arbeitsstunden investiert hast, ohne die spezifische regulatorische und organisatorische Realität der Finanz Informatik GmbH & Co. KG und ihrer Mandanten wirklich zu durchdringen. Der Fehler kostet dich nicht nur das Budget für die Nachbesserung, sondern zerstört das Vertrauen der Institute in deine Lösung für die nächsten zwei Jahre. Wer im Sparkassen-Umfeld überleben will, muss verstehen, dass technische Exzellenz hier nur die Eintrittskarte ist, aber niemals das Ziel an sich.
Die Illusion der grünen Wiese bei der Finanz Informatik GmbH & Co. KG
Ein massiver Fehler, den ich immer wieder sehe, ist der Versuch, moderne Software-Paradigmen eins zu eins auf den zentralen IT-Dienstleister der Sparkassen-Finanzgruppe zu übertragen. Entwickler kommen oft mit der Erwartung, dass sie Architekturen bauen können, die losgelöst von jahrzehntealten Kernbanksystemen funktionieren. Das ist ein teurer Irrglaube. Dieser thematisch verbundene Beitrag könnte Sie auch ansprechen: owl labs meeting owl 3.
Die Wahrheit ist: Wer bei der Finanz Informatik GmbH & Co. KG erfolgreich sein will, muss OSPlus (Operatives Strategisches Gesamtsystem) atmen. Ich habe Projektleiter erlebt, die Millionen in Microservices-Architekturen versenkt haben, nur um am Ende festzustellen, dass die Latenzzeiten bei der Abfrage der zentralen Kundendatenstämme jegliche Performance-Vorteile auffressen. Man baut hier nicht auf einer grünen Wiese. Man baut in einem historisch gewachsenen, hochkomplexen Ökosystem, das auf Stabilität und regulatorische Sicherheit getrimmt ist.
Der Lösungsweg ist schmerzhaft, aber notwendig: Man muss die technische Schuld des Bestandssystems als Design-Parameter akzeptieren, statt sie zu bekämpfen. Das bedeutet, dass man schon in der Konzeptionsphase die Datenstrukturen von OSPlus kennt und nicht erst am Ende versucht, einen Adapter zu schreiben. Wer das ignoriert, zahlt später für jede einzelne Datenbankabfrage einen Preis in Form von Zeit und Komplexität, den kein Budgetplan der Welt auffangen kann. Wie ausführlich dokumentiert in jüngsten Artikeln von t3n, sind die Folgen bemerkenswert.
Warum die Standardisierung dein größter Feind und bester Freund ist
Ein häufiges Missverständnis betrifft die Heterogenität der Sparkassenlandschaft. Viele denken, wenn die Software bei der Sparkasse A läuft, dann läuft sie auch bei Sparkasse B. Schließlich nutzen alle das gleiche Kernsystem. In der Praxis ist das Gegenteil der Fall. Jedes Institut hat eigene Parameter, eigene Freigabeprozesse und eine eigene Risikokultur.
Der Fehler der fehlenden Parametrisierung
Ich habe gesehen, wie Teams Monate damit verbracht haben, einen "perfekten" Prozess hart zu codieren. Sobald das Rollout auf die zweite Welle von Instituten zuging, brach das Kartenhaus zusammen. Warum? Weil die eine Sparkasse die Entscheidungsgewalt beim Marktfolge-Mitarbeiter belässt, während die andere auf vollautomatisierte Scoring-Modelle setzt. Wenn deine Software diese Varianz nicht über Parameter abbilden kann, bist du erledigt.
Anstatt eine Lösung zu bauen, die "einfach funktioniert", musst du eine Lösung bauen, die "konfigurierbar scheitert". Das klingt zynisch, ist aber pure Überlebensstrategie. Du musst dem Administrator in der Sparkasse die Werkzeuge an die Hand geben, damit er das System an seine lokalen Richtlinien anpassen kann, ohne dass ein einziger Entwickler den Code anfassen muss. Das spart nicht nur Geld beim Support, sondern verkürzt die Zeit bis zum tatsächlichen Einsatz in der Fläche massiv.
Die regulatorische Falle und wie man sie umgeht
In keinem anderen Bereich ist die Kluft zwischen "technisch möglich" und "regulatorisch erlaubt" so tief wie im Finanzsektor. Ein klassischer Fehler ist es, Compliance und Revision als Hindernisse zu betrachten, die man ganz am Ende des Projekts "abhakt". Das klappt nicht. Wer so denkt, wird von der BaFin oder der internen Revision im letzten Moment gestoppt.
In meiner Zeit habe ich miterlebt, wie ein innovatives KI-Projekt kurz vor dem Go-Live beerdigt wurde, weil die Erklärbarkeit der Modelle nicht den Anforderungen der MaRisk entsprach. Die Entwickler hatten ein Jahr lang an der Genauigkeit gefeilt, aber keinen Tag an der Dokumentation der Entscheidungswege für die Prüfer gearbeitet. Das war ein Totalverlust von über einer halben Million Euro.
Die Lösung ist eine radikale Transparenz von Tag eins an. Man lädt die Revisoren nicht zur Abschlusspräsentation ein, sondern setzt sie mit an den Tisch, wenn die ersten User Stories geschrieben werden. Ja, das bremst den Anfang aus. Ja, das nervt die agilen Puristen im Team. Aber es ist der einzige Weg, um sicherzustellen, dass das Produkt am Ende auch wirklich produktiv gehen darf. Sicherheit ist im Sparkassen-Umfeld kein Feature, sondern die fundamentale Existenzberechtigung.
Der Vorher-Nachher-Check einer Prozessintegration
Schauen wir uns an, wie ein typischer Integrationsversuch in der Realität abläuft, wenn man die Mechanismen dieses speziellen IT-Umfelds nicht versteht, und wie es aussieht, wenn man es richtig macht.
Vorher: Der naive Ansatz Ein Team entwickelt ein neues Tool zur Dokumentenverwaltung. Sie nutzen modernste Cloud-Technologien und eine schicke Weboberfläche. Die Daten werden in einer eigenen Datenbank gespeichert. Für den Zugriff auf Kundendaten bauen sie eine REST-API-Schnittstelle. In der Testumgebung funktioniert alles prächtig. Doch beim ersten Lasttest im Echtbetrieb bricht die Verbindung zum Host-System ständig ab, weil die Authentifizierungs-Token der Sparkassen-Infrastruktur schneller ablaufen, als die Applikation sie erneuern kann. Zudem stellt die Revision fest, dass die Langzeitarchivierung der Dokumente nicht revisionssicher nach den Grundsätzen der ordnungsmäßigen Buchführung erfolgt. Das Projekt wird gestoppt, das Team muss die gesamte Architektur umbauen, um die zentrale Archivlösung des Kernsystems zu nutzen. Die Verzögerung beträgt neun Monate.
Nachher: Der pragmatische Ansatz Dasselbe Team entscheidet sich von Beginn an gegen eine eigene Datenhaltung für sensible Dokumente. Sie akzeptieren, dass die Benutzeroberfläche vielleicht etwas weniger "hip" aussieht, dafür aber direkt in das Portal der Berater integriert ist. Sie nutzen die vorhandenen Services zur Identitätsprüfung und binden die Archivierung direkt an die zentralen Systeme an. Statt eine eigene API zu erzwingen, nutzen sie die vorhandenen Schnittstellenformate, auch wenn diese technisch umständlicher zu bedienen sind. Das Ergebnis: Die Software geht nach vier Monaten in den Pilotbetrieb. Die Berater müssen sich nicht neu anmelden, die Revision gibt sofort grünes Licht, und die Kosten für den Betrieb sind minimal, weil keine zusätzliche Infrastruktur gewartet werden muss.
Kommunikation mit den Entscheidern in der Sparkassenwelt
Wer glaubt, er könne mit rein technischen Argumenten überzeugen, wird schnell feststellen, dass er gegen Wände redet. Die Entscheider bei den Instituten und beim zentralen Dienstleister denken in Kategorien wie Betriebsstabilität, Migrationsfähigkeit und Kosten pro Buchungsposten.
Ein Fehler, den ich oft beobachtet habe: Ein Dienstleister präsentiert eine Lösung und betont, wie schnell sie zu implementieren ist. Für eine Sparkasse ist Schnelligkeit aber oft ein Warnsignal. Schnelligkeit bedeutet Risiko. Wer Erfolg haben will, muss Sicherheit verkaufen. Man muss zeigen, dass man verstanden hat, wie die Migration von Altdaten funktioniert und wie das System reagiert, wenn die zentrale Leitung für zwei Stunden ausfällt.
Es geht darum, die Sprache der Bankkaufleute zu sprechen, nicht die der Softwarearchitekten. Wenn du sagst: "Wir haben eine hochverfügbare Kafka-Instanz", versteht das niemand. Wenn du sagst: "Selbst wenn das Rechenzentrum in Region A brennt, kann der Berater in Region B den Kreditvertrag innerhalb von fünf Minuten zu Ende bearbeiten", dann hast du ihre Aufmerksamkeit.
Realitätscheck
Es ist an der Zeit für eine ehrliche Bestandsaufnahme. Wenn du denkst, dass du das System der Sparkassen-IT von außen "disrupten" kannst, dann wirst du scheitern. Dieses System ist darauf ausgelegt, sich gegen unkontrollierte Veränderungen zu schützen. Das ist kein Bug, das ist eine eingebaute Schutzfunktion für das Geld der Sparer.
Um hier wirklich etwas zu bewegen, brauchst du einen langen Atem, den du wahrscheinlich unterschätzt. Ein Projektzyklus von zwei Jahren ist völlig normal. Wenn dir nach sechs Monaten die Puste ausgeht, fange gar nicht erst an. Du musst bereit sein, Zeit in Gremiensitzungen zu verbringen, hunderte Seiten Dokumentation für die Revision zu schreiben und dich mit technischen Limitierungen abzufinden, die du eigentlich für überwunden hieltest.
Der Erfolg in diesem Umfeld kommt nicht durch das coolste Produkt, sondern durch die tiefste Integration und das größte Verständnis für die regulatorische Last der Institute. Es ist ein hartes Pflaster, auf dem viele Start-ups und auch etablierte Softwarehäuser schon blutige Nasen bekommen haben. Wer aber die Regeln akzeptiert und innerhalb des Systems an den richtigen Stellschrauben dreht, erreicht eine Reichweite, die in Deutschland ihresgleichen sucht. Aber mach dir keine Illusionen: Es ist ein Marathon in einem schweren Schutzanzug, kein Sprint am Strand. Wenn du das nicht willst, ist dieser Bereich schlichtweg nichts für dich. Es gibt keine Abkürzungen, nur harte, detaillierte Arbeit am Fundament. Wer das begreift, spart sich die ersten 200.000 Euro Lehrgeld, die andere schon vor ihm verbrannt haben.
